Board of Directors and Officers elected
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
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
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
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
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
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
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
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
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
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.


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.


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]
GSoC 2019 Report: Adding NetBSD KNF to clang-format, Final
This report was prepared by Manikishan Ghantasala as a part of Google Summer of Code 2019>
This is the third and final report of the project Add KNF (NetBSD style) clang-format configuration that I have been doing as a part of Google Summer of Code (GSoC) ‘19 with the NetBSD.
You can refer to the first and second reports here:
About the project
ClangFormat is a set of tools to format C/C++/Java/JavaScript/Objective-C/Protobuf code. It is built on top of LibFormat to support workflow in various ways including a standalone tool called clang-format, and editor integrations. It supports a few built-in CodingStyles that include: LLVM, Google, Chromium, Mozilla, Webkit. When the desired code formatting style is different from the available options, the style can be customized using a configuration file. The aim of this project is to add NetBSD KNF support to clang-format and new styles to libFormat that support NetBSD’s style of coding. This would allow us to format NetBSD code by passing `-style=NetBSD` as an argument.
[Read More] [1 comment]
Porting wine to amd64 on NetBSD, third evaluation report
This report was written by Naveen Narayanan as part of Google Summer of Code 2019.
This report encompasses the progress of the project during the third coding period. You can make sense of the overall progress of the project by going through the first evaluation report and second evaluation report.
Wine-4.4 (released on Mar 2019) is working fine on amd64
and i386. I have been able to use a script as a workaround for
the problem of setting LD_LIBRARY_PATH
. My patch for
setting guard size to 0 and hence, precluding Wine from
segfaulting, that got upstreamed, can be
found here.
I have updated the package to the latest development version of
Wine which is Wine-4.13 (released on Aug 2019). I have
added support to Wine pkgsrc packages to run tests using make
test, and at the time of writing, they are failing. I have also
noticed them fail on Linux non-pkgsrc environment and hence, will
require further investigation. Initially, they were disabled
owing to pkgsrc setting FORTIFY_SOURCE
which is a macro that
provides support for detecting buffer overflows. In pkgsrc, the
wip/wine*
packages honor PKGSRC_USE_FORTIFY
variable passing
_FORTIFY_SOURCE
macro accordingly. Programs compiled with
FORTIFY_SOURCE
substitute wrappers for commonly used libc
functions that don't do bounds checking regularly, but could in some
cases. Wine unconditionally disables that via their configure
script because for some platforms that triggered false positives
in the past. However, in my experience, no false positive were
found.