The holidays are approaching, and that also brings to an end the work-term for the Foundation’s two co-op students from the University of Waterloo, Heqing (Scottie) Yan and Zakary Nafziger. Scottie and Zak will be back at school in January continuing their studies. This is the second time the Foundation employed Waterloo students, and two new students will start in January. Here, I’ll describe some of Scottie and Zak’s projects over the term.
One of Scottie’s main projects was working on the FreeBSD port of Google’s Syzkaller project. Syzkaller is an unsupervised, coverage-guided kernel (syscall) fuzzer. It performs syscalls with arbitrary arguments, and uses code coverage data to perturb those arguments to attempt to access as much of the kernel as possible. This allows us to find potential kernel security issues in an automated fashion; if the kernel crashes or misbehaves in some way, Syzkaller logs the event and stores the system call data so that reproduction may be attempted.
Google employee Dmitry Vyukov added initial, basic FreeBSD support to Syzkaller and posted an update to the FreeBSD-hackers mailing list. The Syzkaller controller and infrastructure runs on Linux, and the FreeBSD guest runs under the KVM hypervisor. Scottie first reproduced the setup on a bare metal server at Packet.net to understand how the parts fit together.
One of the challenges with a fuzzer like this is that it has no defined end time for a test run; the longer it executes the more likely it is to find issues. Providing a dedicated server for Syzkaller could be expensive. Hosting providers like Packet.net and Amazon AWS provide “spot instance” pricing where server time is available at a greatly discounted price in times of low demand, with the caveat that use of the server may be terminated when demand rises again.
Scottie developed automated provisioning scripts. After reserving a server in Packet’s spot market, the script installs and starts executing Syzkaller. Results are copied back to a management machine on an ongoing basis and results are exported by a web server, so that developers can inspect the details of any issues found. I expect that Scottie’s work will be deployed in the new year, and that work will be done to improve the support for Syzkaller on FreeBSD.
Our other student, Zak, also worked on several projects this term. One of Zak’s primary projects was developing one technique for deploying Secure Boot for FreeBSD. Many PCs and servers today boot using Unified Extensible Firmware Interface (UEFI) firmware, instead of the legacy Basic Input/Output System (BIOS). One of the features of UEFI is Secure Boot, a protocol and interface which improves resistance to malware or undesired software executing in the boot sequence prior to or instead of the desired software.
A typical Secure Boot deployment involves multiple boot stages, with each stage validating signatures on the next stage: the UEFI firmware validates the bootloader, the bootloader validates the kernel, the kernel validates kernel modules, and so on. This is a complex process, but for many use cases there is a much simpler approach that can be taken, and this is what Zak worked on.
Zak’s project creates a memory filesystem (MFS) image of the kernel and modules, and embeds it into the UEFI bootloader, loader.efi. The monolithic loader+MFS is then signed. That signature covers the entire loader and embedded filesystem including the kernel, modules, and configuration files. If any of these components are tampered with or modified the signature will be invalid, and the UEFI firmware will refuse to execute the loader.
Portions of this functionality required for Zak’s project already existed in FreeBSD, but had not been tested or fully integrated. Zak submitted several changes to fix bugs in the embedded filesystem infrastructure and tooling, which are now available in the FreeBSD tree. Note: We’ll soon publish a guide to using Zak’s work to build a monolithic loader and use it in a Secure Boot environment.
I want to thank Scottie and Zak for an excellent work term and wish them well in their studies over the upcoming school term. I’ll be back next year to introduce our new co-op students and talk about some of the projects they’ll be taking on