• SummerOfCodeIdeas

FreeBSD Google Summer of Code Ideas

How to use this idea list

For students

• 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.
• 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

Skill levels

Remember that GSoC is 12 weeks of full time (30-40 hours/week) work. Choose a project you feel you can realistically do within the 12-week timeline

• C: For C-related ideas, at least some experience coding in C is necessary. 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.

• 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 and knowing how to recompile 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.

Ideas list

---

Kernel Projects

Import the Xen 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 booting a Xen Dom0 from EFI

Description

The current multiboot support in the FreeBSD loader only allows booting a FreeBSD/Xen Dom0 when booted from legacy BIOS. In order to boot a FreeBSD/Xen Dom0 from EFI the FreeBSD loader must implement support for the multiboot2 protocol [0]. This has been recently implemented in both grub and Xen in order to boot Xen plus a Linux kernel from EFI using grub.

The following is a rough list of the task to perform:

• Read and understand the multiboot2 protocol.
• Read the FreeBSD/EFI loader code.
• Implement a PoC that allows booting a Xen kernel from the FreeBSD EFI loader, and provides all the needed information for Xen to boot until Dom0 kernel load at least.
• Implement the remaining bits to pass the FreeBSD kernel, modules and metadata to Xen so it can fully load a FreeBSD/Xen Dom0 from EFI.

[0] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html

---

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.

---

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.

---

PowerPC, ARM, MIPS new platform bring-up

Description

There's a number of PowerPC, ARM, and MIPS SoCs (system-on-chip) that are in consumer grade routers, mobile phones, etc that have chips that are supported by FreeBSD, or nearly supported by FreeBSD. Pick one and get FreeBSD booting on it. Integrate it into the tree.

For PowerPC/ARM/MIPS a lot of code already exists and can likely be made use of for several devices. For new CPUs some very low-level code may well need to be written, which will involve a good understanding of the low-level hardware or a willingness to learn. Some device drivers for e.g. timer devices may also need to be developed.

As each platform is different, it's not possible to suggest a mentor to contact in this description. Instead, it's recommended you email the freebsd-embedded@FreeBSD.org mailing list, detailing the CPU you would like to work on, and appeal for a mentor. If you can't find a mentor, please email soc-admins@FreeBSD.org and we'll assist.

---

Improve support for an embedded CPU/board

Description

FreeBSD has a variable level of support for a wide range of ARM and MIPS CPUs and system-on-chips, but not all of the hardware available on them are supported fully. Some CPUs entirely lack support or do not fully support all available peripherals. For example, sometimes SATA interfaces are not supported, or USB controllers, or graphics hardware, etc. This project is to take a common CPU/embedded board, and write missing drivers and/or improve existing drivers, with the end goal that all peripherals on a particular CPU would be fully supported. See https://wiki.freebsd.org/FreeBSD/arm and https://wiki.freebsd.org/FreeBSD/mips for details on supported boards, though please be aware that these pages are not fully up-to-date.

Suggested CPUs (and boards) include boards based on Allwinner (CubieBoard1, CubieBoard2) or Rockchip (Radxa Rock, Radxa Rock Lite) CPUs, or platforms like the Samsung Chromebook (Exynos 5 CPU) or the BeagleBone (TI AM335x CPU). All of these are available in a number of easily-obtainable boards. Peripherals you should aim to test and/or write/complete support for include SATA controllers, SD/MMC interfaces, I2C and SPI interfaces, sound, graphics hardware (2D only), USB/USB2/USB3, GPIO, wired Ethernet, RNGs, and crypto offload hardware. If there is time, other peripherals such as WiFi and 3D graphics etc support could be investigated, although be aware that each of these could be an entire GSoC-sized project by itself.

Many of these peripherals are under-documented. As a result, this project is likely to involve looking at vendor code and code in other operating systems, determining how that code drives the hardware in question, and implementing equivalent code in FreeBSD. Note that copying code directly from GPL sources is not permitted.

Before signing up to do this task, you should determine exactly how well a platform is supported, either through mailing list discussions, IRC discussions, etc. Please note that it is unlikely that FreeBSD will be able to supply hardware for this project, students are expected to already have access to suitable hardware.

As each platform is different, it's not possible to suggest a mentor to contact in this description. Instead, it's recommended you email the mailing list for the architecture you're wanting to work on (e.g. freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org or freebsd-powerpc@FreeBSD.org), detailing the CPU you plan to work on, and appeal for a mentor. If you can't find a mentor, please email soc-admins@FreeBSD.org and we'll assist.

---

Implementing the Parallel Scheduling Parallel Transmission (PSPAT) subsystem on FreeBSD

Description

Virtual Machines in the data center may legitimately generate millions of packets per second. The hosting platform, hence, needs robust packet scheduling mechanisms that support these rates and, at the same time, provide isolation and dependable service guarantees under all load conditions. Current hardware or software packet scheduling solutions fail to meet all these requirements, most commonly lacking on either performance or guarantees. In particular, scheduling outgoing packets at high rate may cause high locking contention (on the scheduler) among transmitting threads running on different CPUs. This often causes reduced throughput and divergence from the nominal rates. The PSPAT architecture proposes a different approach where scheduling (and actual transmission) is performed by a separate kernel thread, and clients are decoupled from the scheduler using lock-free queues. A first prototype, implemented for the Linux kernel, already shows the benefits of this approach. The student is asked to implement the PSPAT architecture in the FreeBSD kernel, in the following way: 1) Intercept all the packets right before the if_output, and push them to an ad-hoc per-CPU lockless queue (queue implementation is already available) 2) Implement a "scheduler" kernel thread, that reads from the the per-CPU lockless queues and runs the scheduling algorithm (without the need of locking, as it is the only user of the scheduling algorithm). 3) As packets exit the scheduling algorithm, transmit them (in batch), either directly from the scheduler thread or using separate dispatcher threads.

The PSPAT paper is available at http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf. An implementation for the Linux kernel can be found at https://github.com/giuseppelettieri/linux-pspat/tree/pspat-4.13, in the net/pspat directory.

---

Integrate QEMU and libvmm

Description

QEMU is a very popular and feature-rich hypervisor, already available for FreeBSD. However, currently QEMU does not integrated with libvmm to benefit from FreeBSD support for hardware-assisted virtualization. The idea for this project is to: 1) identify the current differences between FreeBSD libvmm and Linux KVM kernel modules (and related APIs) 2) introduce a shim layer inside QEMU to abstract away how QEMU uses these hardware assisted virtualization technologies. 3) extend libvmm to match the features exposed by KVM, so that QEMU can run with hardware acceleration also on FreeBSD.

---

Convert all FDT drivers attachments to be table driven and mark with PNP_INFO

Description

The devmatch infrastructure gives us a way to match up hardware with kernel modules that implement drivers that claim the hardware. One problem, however, is that these drivers need some modification before devmatch can use them. Specifically, they need to have their compatibility scans done via a table, and that table needs to be decorated with a PNP_INFO tag so the compiler and kld_xref extract the metadata that devmatch needs to do its job. In addition, the armv7 GENERIC kernel needs to be trimmed of the drivers that can be loaded like this. 3 different boards from different !SoC families have to successfully boot with their drivers that can be loaded automatically loaded automatically.

---

Convert all PCI drivers attachments to be table driven and mark with PNP_INFO

Description

The devmatch infrastructure gives us a way to match up hardware with kernel modules that implement drivers that claim the hardware. One problem, however, is that these drivers need some modification before devmatch can use them. Specifically, they need to have their device ID scans done via a table, and that table needs to be decorated with a PNP_INFO tag so the compiler and kld_xref extract the metadata that devmatch needs to do its job. The problem is that the PCI drivers are all over the place in terms of how they match device IDs, etc, so work will be needed to move some of the in-line code to tables, some of the tables lookups may be able to be move to standardized routines, etc. There's a lot of these drivers, so a significant subset would be acceptable, but the list must be set up front and shouldn't cherry-pick just the easiest drivers. Trimming GENERIC to show that the converted drivers work is also required.

---

Finishing MPLS implementation

Description

There are old works about adding MPLS stack into FreeBSD, but none are complete:

• melifaro's old-work-in-progress

• Previous GSoC (2008)

This project should refresh/cleanup one of these Work-in-progress. The OpenBSD'MPLS stack or the NetBSD'MPLS stack can be used as inspiration too.

---

Userland projects

IPv6 Userland Cleanup

Description

Several userland network utilities do not work correctly with IPv6.

• rpc.statd(8) is not IPv6 clean.
• rpc.rquotad(8) is not IPv6 clean.

This project could also include a broader survey of other network services in /usr/bin and /usr/sbin to make sure they're all IPv6 clean. This project could be further developed. Some more of this includes:

• remove/rework the about 200 gethostby*() calls all in the base system and contrib to use getaddrinfo().
• make more code to conditionally compile in INET or INET6 support.

---

Dual-stack ping(1) command

Description

Currently there are two tools: ping (for IPv4 networks), and ping6 (for IPv6 networks). Between the two commands there's a lot of duplicate functionality, but there's also a lot of necessary divergence. Unifying these commands (and allowing user selection for IPv4 or IPv6 functionality) would mean only requiring one utility.

Care will need to be taken to not change any output from the commands which may be relied upon in scripts, etc.

---

Dual-stack traceroute(1) command

Description

Currently there are two traceroute tools: traceroute (for IPv4 networks), and traceroute6 (for IPv6 networks). Between the two commands there's a lot of duplicate functionality, but there's also a lot of necessary divergence. Unifying these commands (and allowing user selection for IPv4 or IPv6 functionality) would mean only requiring one utility.

---

elftoolchain bug finding/fixing

Description

The elftoolchain project provides FreeBSD with several commands for handling ELF executables, including "ar", "addr2line", "elfdump", "nm", "strings", amongst others. The GNU Project provides a testsuite which could be used to find bugs and incompatibilities in these tools. The goal here would be to test the elftoolchain tools, and for each issue found, fix it.

---

Move to GENERIC armv7 distribution scripting

Description

FreeBSD has grown a large number of boards over the past few years. Far too many to release images for all the boards for. This project would convert the release tools to generate only a generic image that can have any supported u-boot port overlaid. the u-boot ports would need to be updated with meta-data that would describe how each SoCs or board's u-boot and other pieces are places into an image. A simple user-land script needs to be created to take a u-boot package for board X and the generic bootable distribution and make an image that's bootable on board X.

---

Move to GENERIC armv7 distribution web interface

Description

FreeBSD has grown a large number of boards over the past few years. Far too many to release images for all the boards for. We need a way to securely distribute boot images for dozens or even hundreds of boards. The web app would collect user input, run a script to generate the image, sign the image with a secure signing key, then download the results to the user.

---

Updating FreeBSD/lldb bindings to the new liblldb API

Description

LLDB aims to be a an official debugger for the LLVM project. FreeBSD currently has a port of it using the old API that is slowly being deprecated. This results in lack of support for features such as lldb-server, no support for updates that happen in upstream with respect to the new API and subpar error reporting.

The purpose of this project is to develop a new port of LLDB to FreeBSD using the NativeProcess, NativeThread and NativeRegisterContext APIs in order to allow us to exploit the new features that appear in the generic code in upstream LLDB and fix long-standing bugs in the current port. There is existing code that implements initial functionality based on the NetBSD code which the student could use as a starting point. The first step would be to clearly identify what the current LLDB port supports and identify goals that have to be met in the new port to achieve feature parity, which can be guided by the extensive LLDB test suite.

---

Network Configuration Libraries

Deliverables

A simple tool to configure the network on a laptop to allow a bhyve VM to access the internet.

Use Cases:

• A bhyve VM running on a laptop NAT'd out the laptop's wifi connection
• A bhyve VM bridged to the hosts Ethernet network

Stretch goal: Extend the tool to support configuring network access for standard and VIMAGE jails

Description

Build a libipfw to enable programmatic configuration of the firewall, implement basic functionality to add rules and configure NAT instances.

Optional: relocate most functionality available in the command line interface into the library and replace the replace the command line interface with a thin wrapper around the new library.

Build a libbsdnat that can be used by bhyve VM managers and Jail management tools to configure NAT on the host to allow the guest access to the internet via the host's network. This library will then be extended to handle creating 'port forwarding' rules to expose services in the guest to the public network via the host. Network mappings will be ephemeral and will need to be recreated by the management tools when the VM or jail is restarted.

Possible design for final tool:

• libifconfig - used to create and manage bridge interface for bhyve, epairs for jails
• libbsdnat - Configure NAT for outbound, and port forward rules for inbound.
• libipfw - Used to insert rules routing traffic via above NAT instances.

---

Testing

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.

---

Integration testing for the netmap subsystem

Description

The netmap framework was originally designed to provide a simple and efficient API for applications to directly transmit and receive Ethernet frames to/from physical NICs. However, in recent years netmap has been extended with many features to support fast Inter Process Communication (netmap pipes), virtual switches (VALE), interface monitoring (netmap monitors), Virtual Machine pass-through (ptnetmap), etc., and several options to specify how to bind a netmap file descriptor to a physical or virtual interface. Because of its flexibility and richness of features, netmap has become increasingly complex and hard to maintain or upgrade from a software engineering standpoint, leading to frequent inconsistencies and bugs. This project aims at developing a python library (or equivalently a set of command line tools written in C) that exports the whole netmap API, including the control operations (registering an interface, getting information about interface and pool allocation, etc.), and data transfer operations (transmitting/receiving packets with various patterns, using all the types of netmap ports in several combinations). Once the library is ready, the student would proceed to define a set of positive tests (check that things that are supposed to work do actually work), and negative ones (check that things that are supposed to fail do indeed fail).

The current netmap API (control and data transfer is available in this header file https://github.com/luigirizzo/netmap/blob/master/sys/net/netmap.h. The original netmap paper can be found here http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf.

---

Audit Base for Read-Only and NFS Mount Compatibility

Description

FreeBSD has supported read-only and "root on NFS" for decades but has not experienced consistent testing for compatibility under these circumstances. Issues can include the failure of utilities to create temporary files and locking failures with "databases" such as /etc/pwd.db, /var/db/pkg/local.sqlite and /var/db/xenstore/dbf. Temporary workarounds include tmpfs(5) mounts for directories such as /var/db/<utility>, MD/MFS mounts, iSCSI/FC/ggate devices, or network-based authentication. Long-term solutions can follow the model of pkg(8)'s NFS_WITH_PROPER_LOCKING=yes option.

Search terms to help understand the problem: "NFS flock", "sqlite on NFS". Motivation: "Cloud" and "Container" environments often achieve statelessness via simple mechanisms like read-only and network file system mounts.

---

Build infrastructure

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

---

Ports: Porting third-party software to FreeBSD

CoreCLR: add Microsoft's CoreCLR and CoreFX to the Ports tree.

Description

CoreCLR is the Microsoft NET Core runtime and CoreFX are the .NET Core foundational libraries. Both are required to make Microsoft Powershell usable on FreeBSD.

Some work on porting .NET to FreeBSD exists already, including build bots, however it is not yet at the point where it can be fully bootstrapped yet. This project would involve moving the existing work forwards, ideally to the point where .NET is as usable on FreeBSD as on other platforms.

Once this is complete, it should then be possible to get PowerShell fully functional on FreeBSD.