First release candidate for NetBSD 9.0 available!


December 02, 2019 posted by Martin Husemann

Four months after the start of the release engineering process for 9.0, the first (and hopefully only) release candidate is now available.

The NetBSD 9.0 release comes with many new features and lots of improvements over the NetBSD 8.1 release...

[Read More] [1 comment]

 

Debugging FFS Mount Failures


November 27, 2019 posted by Kamil Rytarowski

This report was written by Maciej Grochowski as a part of developing the AFL+KCOV project.

This report is a continuation of my previous work on Fuzzing Filesystems via AFL. You can find previous posts where I described the fuzzing (part1, part2) or my EuroBSDcon presentation.
In this part, we won't talk too much about fuzzing itself but I want to describe the process of finding root causes of File system issues and my recent work trying to improve this process.
This story begins with a mount issue that I found during my very first run of the AFL, and I presented it during my talk on EuroBSDcon in Lillehammer.

[Read More] [1 comment]

 

Board of Directors and Officers elected


November 20, 2019 posted by William J. Coldwell

Per the membership voting, we have seated the new Board of Directors of the NetBSD Foundation:

  • Taylor R. Campbell <riastadh@>
  • William J. Coldwell <billc@>
  • Michael van Elst <mlelstv@>
  • Thomas Klausner <wiz@>
  • Cherry G. Mathew <cherry@>
  • Pierre Pronchery <khorben@>
  • Leonardo Taccari <leot@>

We would like to thank Makoto Fujiwara <mef@> and Jeremy C. Reed <reed@> for their service on the Board of Directors during their term(s).

The new Board of Directors have voted in the executive officers for The NetBSD Foundation:

President:William J. Coldwell
Vice President: Pierre Pronchery
Secretary: Christos Zoulas
Assistant Secretary: Thomas Klausner
Treasurer: Christos Zoulas
Assistant Treasurer: Taylor R. Campbell

Thanks to everyone that voted and we look forward to a great 2020.

[2 comments]

 

LLDB Threading support now ready for mainline


November 09, 2019 posted by Michał Górny

Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages.

In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support which is taking longer than expected. You can read more about that in my September 2019 report.

So far the number of issues uncovered while enabling proper threading support has stopped me from merging the work-in-progress patches. However, I've finally reached the point where I believe that the current work can be merged and the remaining problems can be resolved afterwards. More on that and other LLVM-related events happening during the last month in this report.

[Read More] [0 comments]

 

Stabilization of the ptrace(2) threads continued


November 04, 2019 posted by Kamil Rytarowski

I have introduced changes to make debuggers more reliable in threaded scenarios. Additionally I have revamped micro-UBSan runtime for newer Clang (version 10git). I have received the OK from core@ to switch our iconv(3) to POSIX conformant iconv(3) and I have adapted where possible and readily known in pkgsrc to the newer API. This month I continued to find a solution to the impasse in LLD that blocks adding NetBSD support.[Read More] [0 comments]

 

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] [1 comment]

 

Threading support in LLDB continued


October 05, 2019 posted by Michał Górny

Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages.

In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support. You can read more about that in my July 2019 report.

I've been on vacation in August, and in September I've resumed the work on LLDB. I've started by fixing new regressions in LLVM suite, then improved my previous patches and continued debugging test failures and timeouts resulting from my patches.

[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] [1 comment]

 

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]

 

Adapting TriforceAFL for NetBSD, Part 3


August 26, 2019 posted by Kamil Rytarowski

Prepared by Akul Pillai as part of GSoC 2019.

This is the third report summarising the work done in the third coding period for the GSoC project of Adapting TriforceAFL for NetBSD kernel syscall fuzzing.
Please also go through the first and second report.

This post also outlines the work done throughout the duration of GSoC, describes the implications of the same and future improvements to come.

[Read More] [0 comments]

 

GSoC 2019 Report: Implementation of compat_netbsd32 DRM ioctl/Getting DRM applications running under compat-linux


August 25, 2019 posted by Christos Zoulas

This article was prepared by Surya P as a part of Google Summer of Code 2019

To begin with where we left off last time, we were able to fix the suse131 package with this commit.This commit adds the GPU-specific bits to the package. And with that we had direct rendering enabled and working.I tested it out with glxinfo and glxgears applications.

localhost: glx_info glx_info output

Testing

In order to make sure that applications did not break with this commit,I tried Libreoffice and to no surprise everything ran as expected without any hiccups.

Then I had to make a choice between porting steam and implementing compat_netbsd32 but since steam had lot of dependencies which needed to be resolved and since implementation of compat_netbsd32 had much more priority I started with the implementation of compat_netbsd32.

Implementing compat_netbsd32 DRM ioctls - The Setup

For the Setup I downloaded i386 sets from the official NetBSD site and extracted it in the /emul directory. I ran some arbitrary programs like cat and ls from the emulated netbsd32 directory to make sure everything ran perfectly without any problems. I then tried running the 32bit glxinfo and glxgears application and to no surprise it kept segfaulting. I ktraced the application and identified the DRM ioctl that needed to be implemented.

Implementing compat_netbsd32 DRM ioctls - The Code

There were several functions which were required for the complete working of the compat_netbsd32 DRM ioctl. We implemented each and every function and had the code compiled. We then made sure that the code compiled both as a module and as well as a non module option with which the kernel can be built.I initially tested the code with 32bit glxinfo and glxgears , and the program didn't segfault and ran as expected.

Implementing compat_netbsd32 DRM ioctls - Testing

In order to test the code I built a test application leveraging the api’s provided in libdrm. It is a very simple application which initializes the DRM connection, setup and draws a gradient on screen and exits. I initially ran it against the native amd64 architecture, but to my surprise the application didn't work as expected. After some hours of debugging I realized that there can be only one DRM master and X was already a master. After exiting the X session and running the application, everything ran perfectly for both amd64 as well as i386 architectures.

localhost: drm_test gradient

What is done

  • The Drm Ioctls implementation of Netbsd has been tested and verified
  • The suse131 package has patched and updated (committed)
  • Compat_netbsd32 DRM ioctls has been implemented (Merged)
  • Subsequently DRM ioctls for emulated 32bit linux as well
  • Created a Test GUI Application for the code (yet to PR)

TODO

  • Create an ATF for the code and merge it into the tree
  • Read the code, look for bugs and clean it up
  • Port Steam and make it available in NetBSD

Conclusion

Completing the tasks listed in the TODO is of highest priority and would be carried over even if it exceeds the GSOC time period.

Last but not the least I would like to thank my mentors @christos and @maya for helping me out and guiding me throughout the process and Google for providing me with such a wonderful opportunity to work with NetBSD community.

[0 comments]