GSoC Reports: Enhancing Syzkaller support for NetBSD, Part 1
This report was prepared by Ayushi Sharma as a part of Google Summer of Code 2020
I have been working on the project - Enhance the Syzkaller support for NetBSD, as a part of GSoc’20. Past two months have given me quite an enriching experience, pushing me to comprehend more knowledge on fuzzers. This post would give a peek into the work which has been done so far.
[Read More] [0 comments]
GSoC Reports: Extending the functionality of NetPGP, Part 1
This report was prepared by Jason High as a part of Google Summer of Code 2020
NetPGP is a library and suite of tools implementing OpenPGP under a BSD license. As part of Google Summer of Code 2020, we are working to extend its functionality and work towards greater parity with similar tools. During the first phase, we have made the following contributions
- Added the Blowfish block cipher
- ECDSA key creation
- ECDSA signature and verification
- Symmetric file encryption/decryption
- S2K Iterated+Salt for symmetric encryption
GSoC Reports: Curses Library Automated Testing, Part 1
This report was prepared by Naman Jain as a part of Google Summer of Code 2020
Introduction
My GSoC project under NetBSD involves the development of test framework of curses library. Automated Test Framework (ATF) was introduced in 2007 but ATF cannot be used directly for curses testing for several reasons most important of them being curses has functions which do timed reads/writes which is hard to do with just piping characters to test applications. Also, stdin is not a tty device and behaves differently and may affect the results. A lot of work regarding this has been done and we have a separate test framework in place for testing curses.
The aim of project is to build a robust test suite for the library and complete the SUSv2 specification. This includes writing tests for the remaining functions and enhancing the existing ones. Meanwhile, the support for complex character function has to be completed along with fixing some bugs, adding features and improving the test framework.
[Read More] [0 comments]
GSoC Reports: Fuzzing the NetBSD Network Stack in a Rumpkernel Environment, Part 1
This report was prepared by Nisarg Joshi as a part of Google Summer of Code 2020
Introduction:
The objective of this project is to fuzz the various protocols and layers of the network stack of NetBSD using rumpkernel. This project is being carried out as a part of GSoC 2020. This blog post is regarding the project, the concepts and tools involved, the objectives and the current progress and next steps.
Fuzzing:
Fuzzing or fuzz testing is an automated software testing technique in which a program is tested by passing unusual, unexpected or semi-random input generated data to the input of the program and repeatedly doing so, trying to crash the program and detect potential bugs or undealt corner cases.
There are several tools available today that enable this which are known as fuzzers. An effective fuzzer generates semi-valid inputs that are "valid enough" in that they are not directly rejected by the parser, but do create unexpected behaviors deeper in the program and are "invalid enough" to expose corner cases that have not been properly dealt with.
Fuzzers can be of various types like dumb vs smart, generation-based vs mutation-based and so on. A dumb fuzzer generates random input without looking at the input format or model but it can follow some sophisticated algorithms like in AFL, though considered a dumb fuzzer as it just flips bits and replaces bytes, still uses a genetic algorithm to create new test cases, where as a smart fuzzer will follow an input model to generate semi-random data that can penetrate well in the code and trigger more edge cases. Mutation and generation fuzzers handle test case generation differently. Mutation fuzzers mutate a supplied seed input object, while generation fuzzers generate new test cases from a supplied model.
Some examples of popular fuzzers are: AFL(American Fuzzy Lop), Syzkaller, Honggfuzz.
[Read More] [0 comments]
GSoC Reports: Make system(3) and popen(3) use posix_spawn(3) internally, Part 1
This report was prepared by Nikita Ronja Gillmann as a part of Google Summer of Code 2020
This is my first report for the Google Summer of Code project I am working on for NetBSD.
Prior work: In GSoC 2012 Charles Zhang added the posix_spawn syscall which according to its SF repository at the time (maybe even now, I have not looked very much into comparing all other systems and libcs + kernels) is an in-kernel implementation of posix_spawn which provides performance benefits compared to FreeBSD and other systems which had a userspace implementation (in 2012).
After 1 week of reading POSIX and writing code, 2 weeks of coding and another 1.5 weeks of bugfixes I have successfully implemented posix_spawn in usage in system(3) and popen(3) internally.
The biggest challenge for me was to understand POSIX, to read the standard. I am used to reading more formal books, but I can't remember working with the posix standard directly before.
The next part of my Google Summer of Code project will focus on similar rewrites of NetBSD's sh(1).
[Read More] [0 comments]
GSoC Reports: Fuzzing Rumpkernel Syscalls, Part 1
This report was prepared by Aditya Vardhan Padala as a part of Google Summer of Code 2020
It has been a great opportunity to contribute to NetBSD as a part of Google Summer Of Code '20. The aim of the project I am working on is to setup a proper environment to fuzz the rumpkernel syscalls. This is the first report on the progress made so far.
Rumpkernels provide all the necessary components to run applications on baremetal without the necessity of an operating system. Simply put it is way to run kernel code in user space.
The main goal of rumpkernels in netbsd is to run,debug,examine and develop kernel drivers as easy as possible in the user space without having to run the entire kernel but run the exact same kernel code in userspace. This makes most of the components(drivers) easily portable to different environments.
Rump Kernels are constructed out of components, So the drivers are built as libraries and these libraries are linked to an interface(some application) that makes use of the libraries(drivers). So we need not build the entire monolithic kernel just the required parts of the kernel.
[Read More] [0 comments]
The GNU GDB Debugger and NetBSD (Part 1)
The NetBSD team of developers maintains two copies of GDB:
- One in the base-system with a stack of local patches.
- One in pkgsrc with mostly build fix patches.
The process of maintaining a modern version (GPLv3) of GDB in basesystem is tainted with a constant extra cost. The NetBSD developers need to rebase the stack of local patches for the newer releases of the debugger and resurrect the support. The GDB project is under an active development and in active refactoring of the code, that was originally written in C, to C++.
Unfortunately we cannot abandon the local basesystem patches and rely on a pristine version as there is lack of feature parity in the pkgsrc version of GDB: no threading support, not operational support for most targets, no fork/vfork/etc events support, no auxv reading support on 64-bit kernels, no proper support of signals, single step etc.
Additionally there are extra GDB patches stored in pkgsrc-wip (created by me last year), that implement the gdbserver support for NetBSD/amd64. gdbserver is a GDB version that makes it possible to remotely debug other programs even across different Operating Systems and CPUs. This code has still not been merged into the mainline base-system version. This month, I have discovered that support needs to be reworked, as the preexisting source code directory hierarchy was rearranged.
Unless otherwise specified all the following changes were upstreamed to the mainstream GDB repository. According to the GDB schedule, the GDB10 branch point is planned on 2020-05-15 with release on 2020-06-05. It's a challenge to see how much the GDB support can be improved by then for NetBSD![Read More] [0 comments]
Accomplishment of porting ptrace(2) test scenarios
This month I have finished porting ptrace(2) tests from other Operating Systems. I have determined which test scenarios were missing, compared to FreeBSD and Linux, and integrated them into the ATF framework. I have skipped some of the tests as the interesting behavior was already covered in existing tests (sometimes indirectly) or tools (like picotrace), or the NetBSD kernel exhibits different behavior.[Read More] [0 comments]
Fundraising 2020
Fundraising drive 2020: trying to raise $50,000 for more funded development projects to fix itching issues.
[Read More] [2 comments]
Approaching the end of work on ptrace(2)
This is one of my last reports on enhancements on
ptrace(2)
and the surrounding code.
This month I complete a set of older pending tasks.[Read More]
[0 comments]
Improving the ptrace(2) API and preparing for LLVM-10.0
This month I have improved the NetBSD
ptrace(2)
API, removing one legacy
interface with a few flaws and replacing it with two new calls with new
features, and removing technical debt.
As LLVM 10.0 is branching now soon (Jan 15th 2020), I worked on proper support of the LLVM features for NetBSD 9.0 (today RC1) and NetBSD HEAD (future 10.0).[Read More] [0 comments]
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]