• 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

Add support for building Linux-only network drivers

Description

Currently we have a Linux KPI for FreeBSD which mostly helps drm-next graphical stack to work.

The big-picture idea is to have network functionalities implemented in that way too, so that we can build "Linux-only" network drivers for FreeBSD too.

For this purpose the first thing we need to do is to implement the API (KPI) most of Linux drivers rely on. Netlink is one of those and among the important ones.

The steps (the first or at max 2nd one are for current/2019 GSoC)

• Implement netlink
  • Implement base functionalities (ioctl behavior)
  • Implement Netlink protocols (NETLINK_ROUTE, FIREWALL, etc)
• Build a sample driver using new API

Further info: https://wiki.freebsd.org/Devsummit/201902#DiscussionNotes

---

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 sanitizers

Description

FreeBSD includes support for the kernel coverage sanitizer and undefined behaviour sanitizer, however support for the other sanitizers is missing. These are useful to find bugs while fuzzing the kernel.

Port one or more of KASAN, KMSAN, and KTSAN to work in the FreeBSD kernel. KASAN is an address space sanitizer, used to find out of bounds accesses. KMSAN is a memory sanitizer, used to find read-before-write and could be used to find kernel memory being disclosed to userspace. KTSAN is the thread sanitizer, used to find data races.

---

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.

---

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.

---

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.

---

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

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.

---

Firewall testing

Description

FreeBSD some tests for the pf firewall, based around VIMAGE jails. These tests can be extended to build a test suite for firewall functionality testing usable on all three (pf, ipfw, ipf) firewalls. Ideally the tests should be able to abstract the differences in the firewall configuration systems so that the same tests can be used on all three. Of course each firewall has unique features, so it should still be possible to write per-firewall tests (e.g. for pfsync).

---

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

---