• SummerOfCodeIdeas

FreeBSD Google Summer of Code Ideas

For students

• You should propose the design of your idea first, and only start coding once your project is accepted. Producing a decent design will save you lots of effort.
• Most mentors are working professionals. Please use their time effectively, with up-front study of issues and problems, and try to provide as much data as possible.

• We have a page at SummerOfCodeDevEnvironments where we detail some possible ideas for how to set up your developer environment.

• We also have several pieces of advice on applying at SummerOfCodeStudentChecklist

• The list of projects here should be regarded as inspiration, not as the exclusive list of all projects that will be considered. We are happy to try to find mentors for projects that will benefit the FreeBSD project. If you're unsure if your idea fits this description, try asking in #freebsd-soc or #bsddev on EFNet.

For mentors

• For best student experience, tasks SHOULD have 2 mentors. Please remember that some students may require significant time for coordination/reviews.
• Consider that students may come with different backgrounds
• A blank template is available at the top of the ideas list when you edit the page

Skill levels

• C: For C-related ideas, general fluency with basic programming in low-level language is necessary. Judge by yourself. You know yourself the best. If you know you barely understand written source-code and you pick a hardcore kernel project, you'll have a problem. You can either treat it as a challenge, commit to doing it and learn FreeBSD by doing, or just pick something simpler. Generally, it is easier to program/debug userland software than it is when working on the kernel. Kernel programming/debugging is harder, and can involve skills ranging from understanding internals of operating systems construction to understanding the computer architecture itself. We encourage picking projects which you feel you can realistically do within the 12-week timeline

• Kernel: The FreeBSD kernel is written in C, so at least a basic proficiency in C is required to choose a kernel project. Various levels of other skills may be necessary, but you can certainly assume that knowing how to do "Hello world" in the kernel should be an essential starting point.

• Network: Understanding of TCP/IP will be required for these projects. It'd be good if you understood socket API for any programming language, and know stuff like "sockets".

• Security: For these tasks you must have general understanding of security issues, UNIX permission model, basics of cryptography and its applications.

• Scripting: For scripting, unless otherwise stated we won't enforce which language you choose, however there are certain factors for this choice: if you're willing to work with /bin/sh (+awk/sed/etc), there is a higher chance that whatever you produce could be committed to the base system. If you pick something like Lua for which we don't currently have base system support, it may still be possible to create a convincing case for the tool to get into the tree, with some level of commitment and convincing. For other things in languages too large for the base system and not present there (e.g.: perl, python, ruby), these can still be offered as useful tools to others, but (e.g.) these would be bad language choices for things that need to be usable with just the base system (e.g. the installer). Tools are equally important as every part of the OS. If you create a tool for debugging, analyzing and visualizing complex data, it might help dozens of FreeBSD hackers around the world to be 10x more productive.

List of ideas

Ideas list

---

FreeBSD/Xen: import the grant-table bus_dma(9) handlers from OpenBSD

Description

In order to implement Xen paravirtualized drivers, an abstract reference to memory pages is used. This mechanism is called grant references and are used in order to exchange information in a safe way between Xen domains. This interface is also extensively used by Xen paravirtualized IO drivers, and it's current implementation in FreeBSD is lacking a proper integration with the rest of the system. OpenBSD has integrated grant references into it's bus_dma(9) subsystem, allowing Xen drivers to use a more transparent integration with the rest of the OS. The aim of this project is to bring the OpenBSD bus_dma(9) grant table handlers from OpenBSD into FreeBSD, expand them in order to support all the grant operations (share and map), and modify the existing frontends and backend in FreeBSD in order to make use of them.

The OpenBSD implementation can be found in src/sys/dev/pv/xen.c and a talk about it at Implementation of Xen PVHVM drivers in OpenBSD

---

Add support for usbdump file-format to wireshark and vusb-analyzer

Technical Contact: hselasky@

Currently it is not possible to graphically see USB traffic. By adding a backend to the above mentioned software packages this can easily be made possible.

The project consists of writing a small amount of C (wireshark) and Python (vusb-analyzer) code.

This is expected to be a 1 month exercise.

Requirements

• Good knowledge of C
• Good knowledge of Python
• Basic knowledge about USB

---

Write a new boot environment manager

Description

Create a replacement for sysutils/beadm

A boot environment (BE) is a ZFS file system that is designated for booting. You can maintain multiple boot environments on a single system.

Generally, new boot environments are creating by doing a copy-on-write clone of the existing boot environment, before performing destructive procedures such as an upgrade. If the procedure fails, the operator can select the previously working boot environment from the boot menu. Other system directories, such as /usr/home are created as separate filesystems, so changes made there are not lost when booting from a previous boot environment.

chroot, and jail support, to test a BE before booting into it.

---

Basic smoke test of all base utilities

Description

Many of the 700+ programs in FreeBSD have no test coverage at all. This particularly problematic when toolchain and system runtime components are updated.

This project aims to create new test infrastructure and automation tools to add trivial tests (i.e. running tool -h or tool --version) to verify that the program is linked properly. Ideally, the tests to add for each program should be detected by a script the parses manpages or runs tools experimentally.

---

Port OpenBSD's pf testing framework and tests

Description

OpenBSD has a number of tests for both the rule parser, and the firewall (using virtualisation).

---

Userspace Address Space Annotation

Description

The Sparse tool allows pointers to be annotated as belonging different address spaces. This is useful in the kernel where user program addresses require special handling (via copyin, copyout, etc) and likewise memory mapped device addresses may require special handling. We would like to annotate userspace pointers arriving from system calls to avoid mistaking such pointers for kernel pointers. In addition to preventing crashes, the discipline of annotating pointers as being userspace pointers paves the way for memory safety implemented by systems like CHERI.

https://sparse.wiki.kernel.org/index.php/Main_Page

---

zstandard integration in libstand

Description

ZStandard (zstd) is a new compression algorithm by the creator of lz4. It offers similar or better compression than gzip, but at much faster compression and decompression speeds.

Adding zstd to libstand to allow decompressing zstd compressed kernel and mfsroot images, augmenting existing lzma and gzip support.

These better compressed, and fast to decompress images will increase performance for network-booted diskless FreeBSD instances.

An additional goal of this project is to provide a capsicum sandboxed version of the zstd frontend (with gzip like syntax).

---

Replace mergesort implementation

Description

Replace mergesort() in libc with a new or existing BSD licensed implementation.

The existing implementation has a limitation such that it cannot sort values smaller than half the size of a pointer (e.g. char's or on 64-bit systems shorts). This makes it unsuitable as a replacement for qsort() and heapsort() and renders it useless on systems with larger pointer sizes.

Write or import a benchmark to validate the performance of the replacement. Perform profiling with gprof(1), pmcstat(8) and/or DTrace.

Improve the existing tests.

---

Test Kload (kexec for FreeBSD)

Description

https://wiki.freebsd.org/Kload

It's like Linux kexec feature, lets you restart the OS very quickly without going via BIOS initialization. You pass the ELF file of the kernel and the current kernel gets overwritten and the new kernel starts.

Requires a great deal of testing

Requirements

• Strong knowledge of C.
• Strong knowledge of computer architecture
• Experience with kernel programming.

---

Kernel fuzzing suite

Description

FreeBSD's memguard(9), and the compiler stack protection offer a good framework to detect memory leaks and buffer overflows in the kernel and the complete OS is frequently checked with static analysis tools, but we lack kernel specific fuzzer testing tools to aid in such detection. Originally the linux Trinity fuzzer was the main example of such tool, Dmitry Vyukov's syzkaller is somewhat more promising, and as of lately there is also the TriForceAFL used for OpenBSD.

A native tool would be good but perhaps just running the Trinity tool under the linux emulator, along with memguard(9), would reveal general bugs in the kernel.

---

Integrate MFSBSD into the release building tools

Description

MFSBSD is a version of FreeBSD designed to run from memory. It is often used as a rescue system, or the basis for automated installers.

It is currently maintained by a FreeBSD developer, Martin Matuška

The issue is that only images for the release versions are usually produced, and MFSBSD tends to get out of sync with the tools in base. There is a desire to have MFSBSD images of the weekly snapshots of -current and -stable that are created by the release engineering time. This requires that the process be automated as an additional target in the makefile in src/release. It would be similar to the process used now to generate VM images. Adding flexibility to the MFSBSD build system to control additional features would be a bonus

---

NVMe controller emulation for bhyve

Description

NVM Express (NVMe) is a standard for accessing high-speed flash storage over PCIe.

An NVMe controller emulation for bhyve would offer a higher performance storage solution for Windows guests compared to AHCI/virtio-block, and would also offer a useful testing platform for future storage development.

The emulation doesn't have to be fully spec-compliant, but in the style of other bhyve device emulations, should have enough functionality to be useable by a number of guest operating systems, in particular recent Linux, Windows and FreeBSD.

---

Verification of bhyve's instruction emulation

Description

Intel VT-x provides very little assistance to the hypervisor when a guest issues an MMIO access, instead leaving it up to the hypervisor to emulate the instruction used by the guest.

bhyve has software emulation of a small number of instructions. However, it is difficult to prove that these emulations are correct. They have to execute in a number of processor modes, and the side effects of the instructions can be intricate.

This project will attempt to create a test harness for the instruction emulation code, perhaps using the open-source Intel XED tool, which should give confidence that the existing code is correct and provide a mechanism to develop future instruction emulation.

---

VGA emulation improvements for bhyve

Description

bhyve ships with a VGA/VESA device emulation, though it is little-used compared to the UEFI frame buffer. However, this is useful for booting older guest o/s's.

There are some functional and performance limitations with this code. For example, text-mode rendering uses most of one CPU even when a guest is idle.

Although a linear frame buffer is available through VESA, this hasn't been significantly tested, and should be verified by running a number of different guest operating systems.

This project will examine the VGA emulation in detail. The student should have an interest in computer graphics as well as virtualization.

---

audit framework test suite

Description

FreeBSD's audit(4) system is a widely used security mechanism for auditing access to the operating system kernel and its facilities, including storage and networking. Although the audit framework itself is quite mature, and is used outside of FreeBSD, notably on Mac OS and related products, it is in need of a set of automated tests so that it can be reliably extended with minimal risk of the introduction of security regressions.

On this project students will learn about computer systems security as well as how security mechanisms are implemented in a production operating system. The ideal student for this project is one who is interested in learning about computer security and security mechanisms permeate the system in a broad way, touching on every service provided by the operating system, including processes, file systems, networking etc.

---

Add more FreeBSD testing to Xen osstest

Description

The current Xen Project test system only has minimal support for FreeBSD: it's able to test a FreeBSD guest, but it's not able to setup a FreeBSD host or perform a Xen compilation on FreeBSD. This project aims to solve this by providing better integration of FreeBSD into the Xen test system (osstest).

First tasks will involve writing the necessary code so that osstest can setup a FreeBSD host and be able to build new FreeBSD host install media, so that we can start tracking FreeBSD upstream. Next steps will involve compiling Xen on FreeBSD and also generating FreeBSD guest install media, so that guests are also tracking upstream FreeBSD.

An initial attempt at this can be found on https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00280.html. The student can use part of this as a baseline if desired.

---

Lua in bootloader

Description

We have a branch (https://svnweb.freebsd.org/base/projects/lua-bootloader/) with some code on bringing lua instead of forth into he bootloader.

Most of the work has been done previously and all what's left is testing and fixing things that doesn't work.

On the Mid-term we expect to have the code staging in the branch "mergeable".

On the Final deliverable we expect to have something that can fully replace the already-existing forth implementation (i.e. Boot Environment etc ...)

---

POSIX compliance testing framework

Description

Standards compliance has always been one of the main objectives for the FreeBSD project. In the past we had some efforts to follow regular testing procdures but we haven't followed up the efforts with proper and sustainable infrastructure. The Open Group has made some testsuites available freely. In particular the FreeBSD port of Tet testing suite should be rescued and the Linux lsb-vsx testuite should be cleaned up so that we are able to do regular testing on both linux-emulation and FreeBSD-native support. Any compliance issue should be reported in bugzilla and an attempt to contact the respective group should be made to draw a plan towards compliance.

---

coreclr: add Microsoft's coreclr and corefx to the Ports tree.

Description

There has already been porting work on getting the .Net implementation to run on FreeBSD, including build bots, however it is not quite bootstrapable as yet. Full support for this is important and we don't want to stop there but also bring Microsoft's PowerShell.