FreeBSD Google Summer of Code Ideas

This page lists FreeBSD project ideas for Google Summer of Code (GSoC). If you plan to apply to work on a FreeBSD GSoC project, you should contact one or more mentors as soon as possible to get feedback. We want to ensure projects have a reasonable chance of being successfully completed.

How to use this idea list

This list of project ideas should be regarded as inspiration, not an exclusive list. You can propose any FreeBSD-related project you want, but whether you apply using your own project idea or one here, we want to see that you thoroughly researched the project in coordination with one or more potential mentors and that you have a clear plan. If you are interested in working with a mentor who is not listed here, you can contact FreeBSD developers using one of these methods.

We also have a few pages that list other project ideas: Ideas Page, Junior Jobs, and Wanted Ports. Note that many of these ideas may not be suitable GSoC projects as-is but may provide inspiration. If you need even more inspiration, here are the GSoC projects from previous years: SummerOfCode2023, SummerOfCode2022, SummerOfCode2021, SummerOfCode2020, SummerOfCode2019, SummerOfCode2018, SummerOfCode2017, SummerOfCode2016, SummerOfCode2015, SummerOfCode2014, SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010, SummerOfCode2009, SummerOfCode2008, SummerOfCode2007, SummerOfCode2006, SummerOfCode2005.

Skill levels

Starting in 2024, projects can be small (~90 hours), medium (~175 hours), or large (~350 hours) and last from 8 weeks to 12 weeks or be extended up to a 22-week work term. Choose a project that you feel you can realistically complete within one of those timelines. Again, mentors can help you gauge how much effort and experience a given project may require.

Kernel Projects

Unified kernel tracing interface

Mentor

Skills

C (advanced), Kernel

Mid-term deliverable

Implementation available for amd64

Duration

350 hours

Difficulty

Hard

Expected Outcome

Existing consumers converted to use the new interface

Description

The FreeBSD kernel contains several subsystems which add hooks to core pieces of the kernel. For example, the context switch code in the scheduler contains this snippet:

        if (td != newtd) {
#ifdef  HWPMC_HOOKS
                if (PMC_PROC_IS_USING_PMCS(td->td_proc))
                        PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_OUT);
#endif
                SDT_PROBE2(sched, , , off__cpu, newtd, newtd->td_proc);

#ifdef KDTRACE_HOOKS
                /*
                 * If DTrace has set the active vtime enum to anything
                 * other than INACTIVE (0), then it should have set the
                 * function to call.
                 */
                if (dtrace_vtime_active)
                        (*dtrace_vtime_switch_func)(newtd);
#endif
                td->td_oncpu = NOCPU;
                cpu_switch(td, newtd, mtx);
                cpuid = td->td_oncpu = PCPU_GET(cpuid);

                SDT_PROBE0(sched, , , on__cpu);
#ifdef  HWPMC_HOOKS
                if (PMC_PROC_IS_USING_PMCS(td->td_proc))
                        PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_IN);
#endif

There are three hooks that may be called before switching into the new thread, and two hooks that may be called after the switch. They are used by DTrace and HWPMC to collect information about context switch events. These hooks are disabled most of the time, but each hook introduces overhead even when disabled since we must check whether it is enabled each time the code is executed.

The goal of the project is to identify useful kernel tracepoints, and design and implement a unified interface that can be used by different consumers to collect information about the event corresponding to a particular tracepoint. This would make it easier for new subsystems to collect information from existing tracepoints, rather than modifying the core kernel to add more hooks. An additional aim would be to ensure that such tracepoints have minimal overhead, probably by using hot-patching to enable and disable a particular tracepoint. FreeBSD-CURRENT now uses clang 10.0, which implements the "asm goto" construct that could be useful here.

Implement MPLS support for FreeBSD

Mentor

Alexander Chernikov <melifaro AT FreeBSD DOT org>

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

MPLS forwarding works on static labels

Duration

350 hours

Difficulty

Medium

Expected Outcome

MPLS forwarding, encap/decap works, MPLS labels can be programmed via Netlink

Multiprotocol Label Switching (MPLS) is an overlay network technology based on labels instead of IP addresses. The project would be to bring basic MPLS support for FreeBSD. Roughly, the implementation can be split into the following chunks:

The OpenBSD's MPLS stack or the NetBSD's MPLS stack overviews of other *BSD implementations can provide more datapoints.

Improve netgraph concurrency

Mentor

Alexander Chernikov <melifaro AT FreeBSD DOT org>

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Traffic is able to pass in a lockless fashion in 2-node netgraph topology

Duration

350 hours

Difficulty

Medium

Expected Outcome

Traffic is able to pass in a lockless fashion between ng_<ppp|car|tee|iface>, compatibility retained with non-converted nodes

Netgraph is a traffic-processing subsystem based on the dynamically configured graph of nodes and directed edges. Each node apply a single specific manipulation to the packet. The core idea is similar to VPP. Currently netgraph uses topology lock and node/hook atomic refcounts to ensure safe passing of the packets between the nodes. The goal of the project is to make passing data between the nodes lockless. The necessary primitives like epoch-based object reclamation and lockless datastructures are available in the base system. The rough implementation sketch may look like the following:

Add IPv6 scoped-address support in in-kernel ONC RPC and NFS

Mentor

Hiroki Sato <hrs AT FreeBSD DOT org>

Skills

C (intermediate), Kernel (intermediate)

Duration

175 hours

Difficulty

Medium

Expected Outcome

NFS works with IPv6-scoped addresses

FreeBSD’s NFS and other implementations relying on ONC RPC do not work with non-global IPv6-scoped addresses (e.g., link-local) because the RPC universal address format specified in RFC 5665 is used and it does not include the scope ID. This project aims to eliminate this limitation. The required steps are as follows:

Userland projects

Port virtual_oss to base

Mentor

Christos Margiolis <christos AT FreeBSD DOT org>

Skills

C (advanced), FreeBSD programming environment (intermediate), DSP (moderate), kernel (basic)

Duration

175 hours

Difficulty

Medium

Expected Outcome

virtual_oss part of the base system

virtual_oss is an audio server written by Hans Petter Selasky for FreeBSD's sound system, OSS (Open Sound System), which provides support for (de-)multiplexing audio devices, switching audio devices on the fly, as well as bluetooth sound, among other features. FreeBSD currently lacks a built-in audio server, since virtual_oss is only provided as a port.

The goal of the project is to successfully port virtual_oss to the base system and integrate it in programs and scripts that might benefit from using it.

Even though this project is largely about integration, virtual_oss uses third-party libraries, namely libsamplerate and fftw3, which will most likely need to be replaced by rolling our own code in order to make virtual_oss completely standalone.

UFS4fuse: support FreeBSD's UFS2 with fusefs

Mentor

Alan Somers <asomers AT FreeBSD DOT org>

Skills

C++ or Rust (expert), fusefs (expert)

Mid-term deliverable

TBD

Duration

350 hours

Difficulty

Hard

Expected Outcome

Read-only fusefs-based UFS2

FreeBSD's UFS is arguably the longest standing UNIX file system still under active development. It is well documented and has many interesting features. While UFS has been ported to Linux and Mac OSX, the ports are not very good or have been deprecated. Using fusefs as a userland option would let the filesystem be used on many other systems. Existing FreeBSD headers and code can be reused but a fresh design using modern C++ or Rust constructs would be interesting.

This project is challenging: any proposal must include a detailed coding plan and a very motivated contributor.

syzkaller improvements

Mentors

Skills

golang (intermediate), kernel (intermediate)

Duration

350 hours

Difficulty

Hard

Expected Outcome

Complete FreeBSD syzkaller extenstions described below

syzkaller is a suite of tools that performs coverage-guided system call fuzzing. Originally targeting Linux, it can now fuzz many different operating system kernels and has been extremely effective at finding bugs, many with security implications. It creates, monitors and fuzzes a set of virtual machines running the target kernel. More information can be found in its documentation, and in these slides. Google kindly runs a public syzkaller instance targeting FreeBSD.

For a while it has been possible to run syzkaller on FreeBSD; that is, fuzz FreeBSD on FreeBSD. syzkaller makes use of ZFS and bhyve (or QEMU) to do so. This makes development and testing of FreeBSD-specific syzkaller features much easier.

Though syzkaller has found quite a few bugs in FreeBSD, it does not cover as much as it does on Linux, so it is virtually guaranteed that there are plenty of bugs waiting to be found. This project consists of several subtasks that would improve FreeBSD's coverage:

Note: contributing to syzkaller requires signing the Google CLA. Please make sure that this is acceptable before attempting this project. Note also that working with syzkaller is probably easiest on a dedicated hardware system with a reasonably large amount of disk space (several hundred GB should be sufficient), ideally running FreeBSD on ZFS. syzkaller can instantiate VMs on Google Compute Engine and fuzz them, so this may be an option as well. Please contact the project mentors for details.

Capsicumization of the base system

Mentor

Mariusz Zaborski <oshogbo AT FreeBSD DOT org>

Co-Mentor

Mark Johnston <markj AT FreeBSD DOT org>

Skills

C (intermediate), familiarity with the UNIX programming environment

Mid-term deliverable

Sandbox a few of the target applications

Duration

350 hours

Difficulty

Medium

Expected Outcome

Sandbox the complete list of target applications

Capsicum is a sandboxing technology used in FreeBSD. It is complemented by Casper, a framework for defining application-specific capabilities. A large number of utilities in the FreeBSD base system have been converted to run under Capsicum and Casper, but many programs have yet to be converted. The project would consist of identifying several high-profile daemons and utilities in the base system or ports, and modifying them to run in capability mode. One good candidate is syslogd, the system logging daemon.

As part of this work it may be necessary or useful to add additional Casper services to the base system. For example, we do not yet have a Casper service which allows an application to make outbound network connections.

Note: Converting applications to run under Capsicum/Casper can take a lot of effort, especially when they are large or when they are not designed with privilege separation in mind. Some applications, like a shell, can't really be run in capability mode at all. Before attempting to sandbox a given application, take care to study the ways in which it interacts with the system. For example, does the application need to open any files? If so, are the file names statically defined or are they derived from user input? This will provide insight into the difficulties that will arise when sandboxing the application.

Network Configuration Libraries

Mentor

Allan Jude <allanjude AT FreeBSD DOT org>

Skills

C (intermediate), knowledge of networking and NAT

Mid-term deliverable

Library to configure IPFW NAT to allow a bhyve VM guest to reach the Internet

Duration

350 hours

Difficulty

Medium

Expected Outcome

A library to manage NAT configuration for VMs and Jails

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

Use Cases:

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

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:

IPv6 support and cleanup of address family dependency in userland utilities

Mentor

Hiroki Sato <hrs AT FreeBSD DOT org>

Skills

C (intermediate), networking (intermediate)

Duration

175 hours

Expected Outcome

More userland utilities with better IPv6 support

Many of our tools are not IPv6 "clean", such as these tools:

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. Other possible work could involve

Speed up the FreeBSD boot process

Mentor

Colin Percival <cperciva AT FreeBSD DOT org>

Skills

C (intermediate), sh (intermediate), kernel (beginner)

Mid-term deliverable

Targets for boot speedup identified and some addressed

Duration

175 hours

Difficulty

Medium

Expected Outcome

FreeBSD will boot faster

Using the TSLOG framework and one or more systems running FreeBSD, profile the boot process and identify targets for improving boot performance. This is likely to involve delving into multiple different parts of FreeBSD, ranging from the kernel to daemons launched from rc.d scripts; there are likely a large number of places where improvements can be made, and work will be guided by the amount of time which could potentially be saved and the likely complexity of making improvements. In many cases, a student will need to collaborate with other FreeBSD developers familiar with different parts of the system.

Make installer more useful

Mentor

Pierre Pronchery <pierre AT FreeBSDFoundation DOT org>, Warner Losh <imp AT FreeBSD DOT org>

Skills

C (intermediate), sh (intermediate)

Mid-term deliverable

Part of the improvements

Duration

175 hours

Difficulty

Medium

Expected Outcome

FreeBSD Installer Disk will allow installing packages

Many people use the FreeBSD installation media to repair malfunctioning systems, test out compatibility and other unconventional uses. The current installer has fallen behind what Linux systems can do in these areas, in no small part because people can add incrementally to the equivalent Linux system. In addition, pkgbase is coming, where the base system will be packaged into bits installable by pkg, FreeBSD's package manager. To those ends, allowing packages to be installed (either locally or via the network) would increase the flexibility of FreeBSD's installation media.

Port of libc SIMD enhancements to other architectures

Mentor

Robert Clausecker <fuz AT FreeBSD DOT org>

Skills

C (intermediate), assembly (advanced)

Mid-term deliverable

Part of improvements

Duration

350 hours

Difficulty

Medium

Expected Outcome

Enhancement of all/most libc string functions on a new architecture.

In 2023, the FreeBSD Foundation sponsored work to reimplement the libc string functions in assembly for better performance. As a result of this work, almost all string functions were reimplemented for amd64 with SIMD techniques, leading to a 5x performance improvement on average. However, this effort currently only benefits users of the amd64 architecture.

This project would entail taking these improvements and expanding or porting them to one or more other architectures, such as arm64, riscv64, powerpc64, or powerpc64le. Previous experience with assembly programming is a strict requirement for this project, but the mentor would help you get familiar with the use of SIMD techniques for string processing.

Ports

New ports tree target: make db

Mentor

Baptiste Daroussin <bapt AT FreeBSD DOT org>, Joe Mingrone <jrm AT FreeBSD DOT org>

Skills

Scripting in lua or sh (intermediate), Database concepts (intermediate)

Mid-term deliverable

Desigin for collection script and database schema, and ideally development of both well underway

Duration

90

Difficulty

Easy

Expected Outcome

Under the ports tree, run make db to collect information into a database

The FreeBSD ports tree is a large collection of "blue prints" for building packages. The collection is very large, with over 30,000 ports at the time of writing, so queries on the tree can be slow. To remedy this, we would like to store the information in a database such as SQLite, so that information can be queried faster. Another benefit of storing this information in a database is that snapshots of the database can be maintained in order to retrieve historical information.

Tools

Improve LLDB on FreeBSD

Mentor

Co-Mentor

Ed Maste <emaste AT FreeBSD DOT org>

Skills

shell scripting (intermediate), Lua (intermediate), debugger use (basic)

Mid-term deliverable

crashinfo invokes LLDB and extracts backtrace, subset of Lua bindings enabled

Duration

350 hours

Difficulty

Medium

Expected Outcome

LLDB Lua bindings at feature parity with Python bindings, crashinfo script successfully uses in-tree debugger, lldb

The LLVM debugger, lldb, is part of the FreeBSD base system. This project aims to extend lldb on FreeBSD in two ways.

1. Improve lldb Lua bindings

lldb supports scripting in C++, Python, and Lua. The Lua bindings are a more recent addition, and some features that would make them much more usable on FreeBSD are missing. The first goal of this project is to improve Lua binding support, add documentation, and bring the Lua bindings to parity with the Python bindings.

Example tasks:

2. Integration lldb into crashinfo

FreeBSD provides a script, /usr/sbin/crashinfo, which runs after a system (kernel) crash and extracts information from the core dump to store in a text file. See the crashinfo man page for more information. crashinfo currently makes use of the GNU debugger, gdb, which must be installed from the package collection or ports tree. The second goal of this project will be to add lldb support to crashinfo, providing the same information that crashinfo's gdb integration provides. (gdb support should be retained in the script and used when gdb is available).

CategoryGsoc

SummerOfCodeIdeas (last edited 2024-03-15T15:50:07+0000 by JosephMingrone)