Stabilization of the ptrace(2) threads

October 10, 2019 posted by Kamil Rytarowski

I have introduced changes that make debuggers more reliable in threaded scenarios. Additionally, I have enhanced Leak Sanitizer support and introduced various improvements in the basesystem.[Read More] [0 comments]


EuroBSDCon 2019

September 25, 2019 posted by Kamil Rytarowski

Submitted by Maciej Grochowski.

This year This year EuroBSDCon took place in Lillehammer Norway. I had the pleasure to attend as a speaker with my talk about fuzzing the NetBSD filesystems.[Read More] [0 comments]


LLVM santizers and GDB regression test suite

September 03, 2019 posted by Kamil Rytarowski

As NetBSD-9 is branched, I have been asked to finish the LLVM sanitizer integration. This work is now accomplished and with MKLLVM=yes build option (by default off), the distribution will be populated with LLVM files for ASan, TSan, MSan, UBSan, libFuzzer, SafeStack and XRay.

I have also transplanted basesystem GDB patched to my GDB repository and managed to run the GDB regression test-suite.[Read More] [1 comment]


Enchancing Syzkaller Support for NetBSD, Part 3

August 27, 2019 posted by Kamil Rytarowski

Prepared by Siddharth Muralee(@R3x) as a part of Google Summer of Code’19

As a part of Google Summer of Code’19, I am working on improving the support for Syzkaller kernel fuzzer. Syzkaller is an unsupervised coverage-guided kernel fuzzer, that supports a variety of operating systems including NetBSD.

You can take a look through the first report to see the initial changes that we made and you can look at the second report to read about the initial support we added for fuzzing the network stack.

This report details the work done during the final coding period where the target was to improve the support for fuzzing the filesystem stack.

Filesystem fuzzing is a relatively less explored area. Syzkaller itself only has filesystem fuzzing support for Linux.

[Read More] [0 comments]


Getting the GNU gdbserver to work

August 12, 2019 posted by Kamil Rytarowski

A number of the remaining reported ptrace(2) bugs are GDB related. The previous support for GDB in NetBSD was in need for refreshment, as it had no support for gdbserver capabilities. The GDB Server is an execution mode of the debugger, which spawns a dedicated process that interacts with its tracee. The process then establishes a link (socket, serial, ...) with the GDB client that is controlled by a programmer.

As NetBSD-9 has finally branched and I keep receiving requests to finish the integration of LLVM sanitizers, I have pushed this task forward too. I have also completed a few leftover tasks from my previous months that still needed fixes.[Read More] [0 comments]


Forking code support in ptrace(2)

July 04, 2019 posted by Kamil Rytarowski

I've finished all the planned tasks regarding fork(2), vfork(2), clone(2)/__clone(2), and posix_spawn(3) in the context of debuggers. There are no longer any known kernel issues for any of these calls. All of the calls are covered with ATF regression tests.[Read More] [0 comments]


Validation and improvements of debugging interfaces

June 05, 2019 posted by Kamil Rytarowski

In the past month, I have introduced correctness and reliability of tracing processes in the kernel codebase.
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.[Read More] [0 comments]


Improvements in forking, threading, and signal code

May 07, 2019 posted by Kamil Rytarowski

I am improving signaling code in the NetBSD kernel, covering corner cases with regression tests, and improving the documentation. I've been working at the level of sytems calls (syscalls): forking, threading, handling these with GDB, and tracing syscalls. Some work happens behind the scenes as I support the work of Michal Gorny on LLDB/ptrace(2) features.[Read More] [0 comments]


Announcing Google Summer of Code 2019 projects

May 07, 2019 posted by Leonardo Taccari

Google Summer of Code logo We are very happy to announce The NetBSD Foundation Google Summer of Code 2019 projects:

The communiting bonding period - where students get in touch with mentors and community - started yesterday. The coding period will start from May 27 until August 19.

Please welcome all our students and a big good luck to students and mentors!

A big thank to Google and The NetBSD Foundation organization mentors and administrators!

Looking forward to a great Google Summer of Code!



Continuation of signal semantics improvements

April 04, 2019 posted by Kamil Rytarowski

Over the past month I've finally managed to correct masking semantics of crash signals (SIGSEGV, SIGTRAP, SIGILL, SIGFPE, SIGBUS). Additionally I've fixed masking semantics in forks(2) and vforks(2) (they trigger a crash signal SIGTRAP). There is remaining work in signal semantics for other types of events (mainly thread related). The coverage of signal code in ptrace(2) regression tests keeps continuously incrementing.[Read More] [0 comments]


Increasing coverage of signal semantics in regression tests

March 04, 2019 posted by Kamil Rytarowski

Kernel signal code is a complex maze, it's very difficult to introduce non-trivial changes without regressions. Over the past month I worked on covering missing elementary scenarios involving the ptrace(2) API. Part of the new tests were marked as expected to success, however a number of them are expected to fail.[Read More] [0 comments]


Integration of the LLVM sanitizers with the base system

February 01, 2019 posted by Kamil Rytarowski

Over the past month I've merged the LLVM compiler-rt sanitizers (LLVM svn r350590) with the base system. I've also managed to get a functional set of Makefile rules to build all of them, namely:
  • ASan
  • UBSan
  • TSan
  • MSan
  • libFuzzer
  • SafeStack
  • XRay
In all supported variations and modes that are supported by the original LLVM compiler-rt package.[Read More] [2 comments]