strace is taking part in the GSoC 2017 as a mentor organization.

About strace project.

strace is a diagnostic, debugging and instructional userspace tracer for Linux. It is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state. The operation of strace is made possible by the kernel feature known as ptrace.

strace is one of the longest running open source projects and started even before Linux started.

strace is an important tool for debugging and tracing deployed on all Linux distributions and most Unix distributions with a small community of active contributors.

While strace is a small project, the strace tool is essential for many developers, system administrators and open source projects. Its maintainers and contributors are experienced developers.

The project organization is simple: the community discusses proposed patches and a few core maintainers eventually accept or reject contributions. All contributions are submitted as git patches to the mailing list, which is the single point of communication, in a mode very similar to the ways of the Linux kernel.

strace release cycle is currently synchronized with the release cycle of the Linux kernel.

Note that we are pretty laid back and cool compared to larger and professional projects like the Linux kernel but our standards are high and the people involved in strace are die hard system coders often contributing to or maintaining major C libraries such as Glibc, Glib or Bionic, contributing to the Linux Kernel and other major free and open source projects.

So we expect that you would be making the efforts to learn our mailing list and patch ways and ask good questions and do your home work for a most productive and efficient participation.

What to do as a prospective student.

We want engage with students that are interested in system programming and want to help making strace a better tool. We hope to gain you as a new long term contributor and that you will contribute interesting and new features.

You need to grok C and have an interest in system programming and debugging. The codebase is not huge but the domain is not simple and requires a meticulous attention to many details.

All the communication is going through a single mailing list: https://lists.sourceforge.net/lists/listinfo/strace-devel

Subscribe to the list, introduce yourself and start the discussion!

Please prefix your email subjects with GSOC.

~~~~ Please be kind enough to follow these simple guidelines when posting to the list:

  1. only send text emails. No HTML
  2. do not top post
  3. use and abuse the mailing list archive to see how proper discussions are handled
  4. be patient, a reply may need a week to come by
  5. use git tools to create and submit patches to the list
  6. apply to your code the same code style and indentation used overall in strace

Thank you! ~~~~ — https://sourceforge.net/p/strace/mailman/message/34924899/

Check our list of projects ideas below or submit new ideas to the list for consideration.

It is required that students who want to apply to the strace project for the GSoC 2017 complete a relatively small code-related "microproject" as part of their application. Please refer to our guidelines and suggestions for [Microprojects] for more information. Completing a microproject is not only an important way for us to get experience with applicants, but it will also help applicants become familiar with strace's development and submission process.

General Proposal Requirements.

You will need to submit your official proposal via https://summerofcode.withgoogle.com and plain text is the way to go. Please subscribe to the strace-devel mailing list and post your proposal there too. We expect your application to be in the range of 1000 words. Anything less than that will probably not contain enough information for us to determine whether you are the right person for the job. Your proposal should contain at least the following information, plus anything you think is relevant:

Beyond your proposal you need obviously to be familiar with C and Git (or willing to learn these two super quick).

List of project ideas for students.

Comprehensive test suite. Suggested by: Eugene Syromyatnikov, Dmitry V. Levin

The test suite we have today is far from covering all branches of all parsers yet. According to Codecov, current test coverage is just over 80%, but it tells very little about coverage of various corner cases (checks for type sizes, signedness, handling of pointers to invalid memory, etc).

The goal of this project is to improve the test suite to a level that makes strace more reliable.

On the one hand, it would be educational for any student who is interested in syscall internals because writing syscall parsers and tests for them is the second best way to find out how syscalls work.

On the other hand, a comprehensive test suite is a prerequisite for any major change in strace source code. This test suite project does not have to be a work from scratch, there are already existing tests (e.g. strace/tests, ltp/testcases/kernel/syscalls, and sandbox/tests) that could be used as a starting point.

Netlink socket parsers. Suggested by: Gabriel Laskar, Dmitry V. Levin

Netlink is a network protocol that is used to communicate between the kernel and the userspace. For example, iproute use netlink in order to configure the network stack (interfaces, addresses, routes, etc). It is also used by the kernel to report hotplug events to the userland.

The goal here is to add support in strace to decode netlink packet structures in order to be able to debug and discover netlink messages.

In 2016, the base ground work was done, now it can be extended to support more netlink family protocols.

Support for alternative backends. Suggested by: Eugene Syromyatnikov

Add support for providing various backends for strace.

There is one backend already in development (gdbserver), but the way its support has been introduced is rather hackish: https://github.com/cuviper/strace/ https://sourceforge.net/p/strace/mailman/strace-devel/thread/d967f64d-7660-3d45-7d2b-dfbd2cba54fe%40redhat.com/#msg35598297

There is also an idea that uprobes can be utilized for tracing syscalls as a more modern way of tracing processes, which makes the possible support for various tracing backend more useful.

seccomp-assisted syscall filtering. Suggested by: Dmitry Levin

SECCOMP_RET_TRACE seccomp API could be used to implement a more efficient syscall filtering. Using this technique, tracees will be stopped on entering filtered syscalls only instead of all syscalls.

Advanced syscall information tool. Suggested by: Dmitry Levin

A tool that prints all kinds of information about syscalls, including, but not limited to,

Advanced syscall tampering. Suggested by: Eugene Syromyatnikov, Dmitry Levin

In 2016, strace has been extended to tamper with tracees using syscall fault injection. These tampering capabilities of strace could be extended further to support more complex scenarios by tampering with tracee's syscall arguments and the memory they reference. For the maximum flexibility, an API could be added for describing this tampering using some scripting language.

Advanced syscall filtering syntax. Suggested by: Eugene Syromyatnikov, Dmitry Levin

strace supports several qualifying expression types which could be used to configure filtering of syscalls being monitored (-e trace, -e verbose, -e abbrev, etc). With addition of various injecting capabilities, this filtering mechanism starts showing its limitations as it does not support a clear separation of various filtering aspects. For example, it is not possible to filter some syscalls for a specific path and others for another path simultaneously, or inject success to the 2nd open syscall and failure to the 5th one. At the same time, one can find several filtering languages like pcap-filter(7) that support filtering expressions of arbitrary complexity.

For example, the following pcap-like filtering expression could be used to specify filtering of all open syscalls and also all read syscalls performed on path "/path/to/a": ~~~ syscall open or (syscall read and path "/path/a/") ~~~ The following expression specifies success injection to the 2nd unlink syscall and fail injection to the 5th one: ~~~ inject unlink:when=2:retval=0 or inject unlink:when=5:error=ENOENT ~~~

Other ideas

We are also open to any suggestions not listed on this page.

Some existing ideas are present on a separate page. Note, however, that they may be not adequately sized for a GSoC project or require specific qualifications.

GoogleSummerOfCode2017 (last edited 2018-02-26 06:04:42 by eSyr)