Validation and improvements of debugging interfaces
<p>
In the past month, I have introduced correctness and reliability of tracing processes in the kernel codebase.
<br>
I took part in BSDCan 2019 and during the event wrote a NetBSD version of truss,
a ptrace(2)-powered syscall tracing utility from FreeBSD.
I've finished the port after getting back home and published it to the NetBSD community.
This work allowed me to validate the ptrace(2) interfaces in another application
and catch new problems that affect every ptrace(2)-based debugger.
<p>
<h1>Changes in the basesystem</h1>
<p>
A number of modifications were introduced to the main NetBSD repository which include ptrace(2), kernel sanitizer, and kernel coverage.
<p>
Improvements in the ptrace(2) code:
<ul>
<li>Reporting exec(3) events in the PT_SYSCALL mode. This simplifies debuggers adding MI interface to detect exec(3) of a tracee.</li>
<li>Relax prohibition of Program Counter set to 0x0 in ptrace(2). In theory certain applications can map Virtual Address 0x0 and run code there.
In practice this will probably never happen in modern computing.</li>
<li>New ATF tests for user_va0_disable sysctl(3) node checking if PT_CONTINUE/PT_SYSCALL/PT_DETACH can set Program Counter to 0x0.</li>
<li>Fixing kernel races with threading code when reports for events compare with process termination.
This unbroke tracing Go programs, which call exit(2) before collecting all the running threads.</li>
<li>Refreshed ptrace(2) and siginfo(2) documentation with recent changes and discoveries.</li>
</ul>
<p>
I mentor two GSoC projects and support community members working on kernel fuzzers.

As a result of this work, fixes are landing in the distribution source code from time to time.

We have achieved an important milestone with being able to run NetBSD/amd64 on real hardware with
Kernel Undefined Behavior Sanitizer without any reports from boot and execution of ATF tests.
This achievement will allow us to enable kUBSan reports as fatal ones and use in the fuzzing process,
capturing bugs such as integer overflow, use array out of bounds, invalid shifts, etc.
<p>
I have also introduced a support of a new sysctl(3) operation: KERN_PROC_CWD.
This call retrieves the current working directory of a specified process.
This operation is used typically in terminal-related applications
(tmux, terminator, ...) and generic process status prompters (Python psutils).
I have found out that my terminal emulator after system upgrade doesn't work correctly
and it uses a fallback of resolving the symbolic link of <code>/proc/*/cwd</code>.
<ul>
<li>Report TRAP_EXEC (for exec()) to a debugger in the PT_SYSCALL mode</li>
<li>Relax prohibition of Program Counter set to 0x0 in ptrace(2)</li>
<li>Add get_user_va0_disable() in t_ptrace_wait.h</li>
<li>Add new user_va0_disable* tests in t_ptrace_wait*</li>
<li>Update the ptrace(2) documentation</li>
<li>Document TRAP_SCE and TRAP_SCX in siginfo(2)</li>
</ul>
<p>
<h1>ptrace(2) utilities</h1>
<p>
In order to more easily validate the kernel interfaces I wrote a number of utility programs that use the ptrace(2) functionality.
New programs reuse the previously announced picotrace (<https://github.com/krytarowski/picotrace) code as a framework.
<p>
Some programs have been already published, other are still in progress and kept localy on my disk only.
New programs that have been published so far:
<ul>
<li>NetBSD truss - reimplementation from scratch of FreeBSD truss for the NetBSD kernel.</li>
<li>sigtracer - stripped down picotrace reporting signal events.</li>
<li>coredumper - crash detector and core(5) dumper regardless of signal handing or masking options in programs.</li>
</ul>
<p>
More elaborated introduction with examples is documented on the GitHub repository.
I use these programs for profit as they save my precious time on debugging issues
in programs and as validators for kernel interfaces as they are working
closely over the kernel APIs (contrary to large code base of GDB or LLDB).
I've already detected and verified various kernel ptrace(2) issues with these programs.
With a debugger it's always unclear whether a problem is in the debugger,
its libraries or the kernel.
<p>
Among the detected issues, the notable list of them is as follows:
<ul>
<li>Reporting events to a debugger in the same time from two or more sources is racy and one report can be registered and other dropped.</li>
<li>Either questionable or broken handling of process stopped by other process with a stop signal.</li>
<li>Attaching to sleeping process terminates it as interrupted nanosleep does not return EINTR.</li>
<li>Exiting of a process with running multiple threads broken (fixed).</li>
<li>Attaching to applications due to unknown reasons can sometimes kill them.</li>
<li>Callbacks from pthread_atfork(3) (can?) generate crash signals unhandled by a tracer.</li>
</ul>
<p>
<h1>Update in Problem Report entries</h1>
<p>
I've reiterated over reported bugs in the gnats tracking system.
These problems were still valid in the beginning of this year and are now reported to be gone:
<ul>
<li>kern/52548 (GDB breakpoint does not work properly in the binary created with golang on NetBSD (both pkgsrc/lang/go and pkgsrc/lang/go14).)
<li>kern/53120 (gdb issues with threaded programs)
<li>bin/49662 (gdb has trouble with threaded programs)
<li>port-arm/51677 (gdb can not debug threaded programs)
<li>kern/16284 (running function in stoped gdb causes signal 93)
<li>bin/49979 (gdb does not work properly on NetBSD-6.1.1/i386)
<li>kern/52628 (tracing 32-bit application on 64-bit kernel panic)
<li>kern/51420 (gdb hangs waiting for traced threaded child under compat_netbsd32)
</ul>
<h1>Summary</h1>
<p>
There are still sometimes new bugs reported in ptrace(2) or GDB,
but they are usually against racy ATF test and complex programs.
I can also observe a difference that simple and moderately complex
programs usually work now and the reports are for heavy ones like
firefox (multiple threads and multiple processes).
<p>
I estimate that there are still at least 3 critical threading issues to be resolved,
races and use-after-free scenaris in vfork(2) and a dozen of other more generic problems
typically in signal routing semantics.
<p>
<h1>Plan for the next milestone</h1>
<p>
Cover with regression tests the posix_spawn(2) interface,
if needed correct the kernel code.
This will be followed by resolving the use-after-free scenarios in vfork(2).
This is expected to accomplish the tasks related to forking code.
<p>
My next goal on the roadmap is to return to LWP (threading) code and fix all currently known problems.
<p>
Independently I will keep supporting the work on kernel fuzzing projects within the GSoC context.
<p>
<h2>This work was sponsored by The NetBSD Foundation.</h2>
<p>
The NetBSD Foundation is a non-profit organization and welcomes any 
donations to help us continue funding projects and services to the 
open-source community. Please consider visiting the following URL to 
chip in what you can:
<p>
<a href="http://netbsd.org/donations/#how-to-donate">http://netbsd.org/donations/#how-to-donate</a>