• SummerOfCodeIdeas

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.

• Send an email to the <freebsd-hackers AT FreeBSD DOT org> mailing list.

• Join the #freebsd-soc IRC channel on the Libera.Chat network. We use this channel for communication during both the application period and the coding period. You can join the channel either using an IRC client like irssi, or using Libera.Chat's web client. You can read about how to connect to the Libera.Chat network. Due to timezone differences, there may be delays before questions are answered, so please be patient.

• If you do not get a response on IRC or on the mailing list, you can email <soc-admins AT FreeBSD DOT org>.

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, see SummerOfCode for projects from previous years.

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.

• C: For C-related ideas, at least some experience coding in C is necessary. Generally, it is easier to work on the userland than the kernel. Kernel programming and debugging are harder and can involve skills ranging from understanding operating system internals to computer architecture.

• Kernel: The FreeBSD kernel is written in C, so at least a basic proficiency in C is required for 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 TCP/IP will be required for these projects. It would be beneficial if you understood socket API for any programming language and understood how sockets work.

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

• Scripting: For scripting projects, unless otherwise stated, we won't enforce a specific scripting language on you. However, there are certain factors to consider. If you are willing to work with /bin/sh (+awk, sed, etc.) or Lua, there is a chance that whatever you produce could be committed to the base system. If you pick something like bash, which is not part of FreeBSD's base system, your tool can only be considered for the ports tree, which is a repository with instructions to build third-party software for FreeBSD.

LLM Policy

We recognize that Large Language Models (LLMs) can be powerful productivity aids. However, these tools can produce incorrect, misleading, or poorly understood output. To uphold submission quality and to ensure that GSoC remains a learning-focused program, we have established the following policy on LLM usage.

No "Regurgitation"

We will not accept project proposals, code, or documentation primarily generated by an LLM. All submissions must reflect the contributor’s own original work. Submissions that do not meet these standards may result in the rejection of a proposal or failure of a project at evaluation.

Discretionary and Limited Use

LLM usage may be permitted only with the explicit prior agreement of your mentor(s). If permitted, an LLM may be used to assist with:

• debugging self-authored code
• improving, proofreading, or translating text
• researching background information about a problem.

All results must be critically evaluated and fact-checked by the contributor. Mentors may prohibit LLM usage entirely for specific projects if it interferes with learning objectives.

Full Disclosure

If your mentor permits LLM usage within the bounds described here, any usage must be clearly disclosed by the contributor. Disclosure must include descriptions of:

• the tool(s) used
• the type of assistance provided
• any code or documents created with LLM assistance.

Failure to disclose LLM usage will be treated as a policy violation.

Kernel Projects

Kernel/EFI Boot Counter for Early-Boot HMAC

[Last updated: 2026-03-01]

Overview

The FreeBSD base system does not have a persistent reboot counter. This project will implement a kernel-level boot counter using UEFI firmware's Monotonic Counter service as an independent source of truth. The counter will:

• provide a stable, increasing value that survives reboots without depending on filesystem state or userland initialization
• increment on each successful boot and be exposed to userland via a sysctl interface
• consumed by early-boot networking components and monitoring systems

The project will involve a lot of EFI "code spelunking", and only a small amount of coupling to the rest of the system. The contributor will gain experience in kernel development, EFI firmware interfaces, early boot sequencing, and integration with networking and SNMP subsystems.

Motivation

Many network protocols rely on message authentication based on Hash-based Message Authentication Code (HMAC). During early boot, inputs to these HMACs may be deterministic if sufficient entropy is not yet available. Incorporating a persistent boot counter into HMAC inputs can:

• Reduce replay-attack risk
• Avoid reliance on early PRNG state
• Introduce non-determinism without injecting arbitrary randomness
• Provide a monotonic, firmware-backed source of truth
• Potential consumers include:
  • RFC 6740-related mechanisms
  • ILNP
  • SCTP
  • CARP

  • WireGuard

  • IPv6 interface identifier generation

Proposed Implementation

The contributor will:

• implement a new kernel module implementing an EFI-backed monotonic counter
• create a fallback strategy for non-UEFI platforms
• provide a read-only sysctl interface (e.g., kern.bootcount) for the boot counter
• expose the counter through our native SNMP agent, bsnmpd.
• create documentation (e.g., bootcount(4) or kern.bootcount(9))

Stretch goals:

• provide a kernel KPI for HMAC consumers to access the boot counter directly
• integrate the counter into one selected networking subsystem as a proof of concept
• investigate secure storage or tamper-detection guarantees if supported by firmware

Port or reimplement udmabuf

[last updated: 2026-01-15]

udmabuf is a Linux API that allows userspace programs to create DMA-BUFs from user memory (through passing a memfd), allowing e.g. the compositor to import this DMA-BUF directly instead of having to do an explicit GPU upload if just using shm.

I2S sound support for Raspberry Pi

[last updated: 2026-01-17]

I2S is a protocol for digitally transmitting audio, e.g. from small boards like the Raspberry Pi to DACs (such as Adafruit's I2S 3W Stereo Speaker Bonnet).

FreeBSD already supports I2S sound on the Allwinner A64, Allwinner H3, Rockchip RK3066, and Rockchip RK3399, but it would be nice to support I2S on the Raspberry Pi, as it is the most popular SBC and a lot of peripherals/hats use this. As far as I can tell even newer Pis which don't use the BCM2835 chip show brcm,bcm2835-i2s in their device tree, and a single driver should work across all models.

This could either involve extending LinuxKPI so we can build Linux I2S drivers on FreeBSD, which would have the advantage of enabling faster bring-up on new/more obscure SBCs on FreeBSD, or written from scratch.

Other than the source code, the best technical reference for FreeBSD is the classic textbook The Design and Implementation of the FreeBSD OS which should be available in your nearest university library.

Implement a new VLAN filtering software bridge

[last updated: 2025-01-24]

The existing if_bridge(4) driver impedes FreeBSD suitability as a host for virtual machines and vnet enabled jails in design and implementation. Its configuration interface encourages misconfigurations by being too permissive, yet it lacks expected features.

Other operating systems have encountered similar design problems with their respective bridge drivers. After two attempts, OpenBSD came up with a clean design we can learn from: veb(4) and vport(4).

Our bridge member interfaces remain usable as IP capable interfaces which violates IP's (both v4 and v6) interface scope rules. Several bhyve and jail managers attempt to use this to add already configured network interfaces as member to bridges they manage with minimal changes to the host network configuration resulting in unreliable IPv4 and completely broken IPv6 processing. The new driver should restrict member interfaces to be only switch ports refusing to add member interfaces with configured IP addresses and prevent adding IP addresses to members.

In its current state the if_bridge(4) driver does not support VLAN filtering between member interfaces. Neither adding the (untagged) network interfaces nor creating one bridge per VLAN nor and using vlan(4) interfaces as members provides the correct semantics needed. Using IPFW express VLAN filtering between member interfaces or a member interface and a bridge interface is both slow and error prone. The new bridge driver should perform per member port VLAN and MAC address filtering.

Unlike if_bridge(4) the new driver should not be an IP capable network interface. Instead virtual member ports should be created to connect the host to the bridge, acting similar to one half on an if_epair(4).

Such a bridge would also provide the groundwork to improve bhyve(8)'s para-virtualised networking with an if_tap(4) like member port supporting multiple bidirectional packet transfers with a single system call.

Unified kernel tracing interface

[last updated: 2024-03-15]

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.

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

[last updated: 2024-01-31]

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:

• Implement a function handling text representation of an IPv6 address with the scope ID and replace inet_ntop() with it.
• Add support for IPv6-scoped address format to conversions between a taddr and a uaddr in the kernel.

Implement MPLS support for FreeBSD

[last updated: 2023-01-27]

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:

• create MPLS routing tables, analogous to AF_INET[6] routing tables
• add the logic to handle MPLS packets (mpls_input(), mpls_forward(), mpls_output()) at various stages
• add the code to perform MPLS encap for IPv4/IPv6 routes, extending nexthops functionality
• add Netlink support for working with IP-MPLS, MPLS-MPLS and MPLS-IP routes
• Add userland support for working with MPLS routes to route(8) and netstat(8)
• [stretch] add fast fib lookup module to enable high-performance concurrent label lookups

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

Improve netgraph concurrency

[last updated: 2023-01-27]

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:

• Enable delayed reclamation of netgraph hooks and nodes under existing NET_EPOCH

• Make core API like ng_address_hook() leverage existing NET_EPOCH and avoid taking topology locks / refcounts

• Test the implementation with a number of stateless nodes like ng_patch or ng_tee and ng_ipfw
• Evaluate and convert nodes on per-node basis on their reliance on the topology lock

Userland projects

Capsciumize fts(3)

[last updated: 2026-01-17]

The fts(3) family of functions are used to traverse an entire directory tree. They are used by almost every program that has a --recurse option. Yet they do not work with Capsicum. That means that many of FreeBSD's builtin utilities, like ls, rm, find, etc, are not Capsicumized. There are also networked programs likeOpenRsync that use fts, and they could greatly benefit from the addition of Capsicum. This project will add an fts_openat function. It will work like fts_open, but take a directory file descriptor argument like openat. That will likely require adding fields to struct FTSENT, which is allowed, and will be backwards-compatible with the old fts_open. With those two small changes, and some additional changes within the C library, it should be possible to use fts functions in capability mode.

The fts family of functions are very complicated, and currently have poor test coverage. So the first step of this project, and likely the largest, will be to write a set of regression tests for the existing behavior.

IPv6 support and cleanup of address family dependency in userland utilities

[last updated: 2024-02-11]

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

• rwhod(8)
• Various yp(8) daemons
• rpc.rquotad(8)

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

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

Network Configuration Libraries

[last updated: 2024-01-29]

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

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.

• netlink - Used for network stack configuration

ext2fs user space tools

The ext2 family of file systems (ext2/ext3/ext4) is a popular family of file systems originating from the Linux® operating system. Thanks to the tireless work of our contributors, FreeBSD has fairly mature read/write support for ext2, ext3, and ext4 through the ext2fs(4) driver, though features such as extended attributes, journaling, and encryption remain unimplemented. The goal of this project is to complement ext2fs(4) with a suite of user space tools for routine file system tasks. While such tools are available as third-party packages in port filesystems/e2fsprogs, we do not ship them in base due to their GPL license.

While third-party tools can be installed in many circumstances, there are situations were having them on board is preferable. For example, with built-in ext2fs tools, bsdinstall(8) can create ext2fs file systems during system installation, offering greater flexibility and interoperability with Linux® installations. On platforms like POWER®, this would allow us to use ext2fs over msdosfs for storing files accessed by the boot loader (i.e. /boot), improving resilience and I/O performance, as well as permitting standard UNIX file system permissions to be used.

The desired set of tools includes, in decreasing order of importance:

• newfs_ext2fs(8) – create ext2/ext3/ext4 file systems
• makefs(8) support for ext2/ext3/ext4 – create pre-populated ext2/ext3/ext4 images
• fsck_ext2fs(8) – check ext2/ext3/ext4 file systems for consistency and repair them
• tunefs_ext2fs(8) – reconfigure ext2/ext3/ext4 file systems and in particular to change their disk labels
• growfs_ext2fs(8) – resize an ext2/ext3/ext4 file system

As an easy starter, a simple version of newfs_ext2fs(8) can be obtained from NetBSD, adapted to FreeBSD, and augmented to support ext3 and ext4. The project size is variable and depends on how many tools the student wishes to cover. The naming and feature set of the tools proposed above is not set in stone and can be adjusted as needed. Prospective students should bring C programming skills as well as a good understanding of the data structures of the ext2 family of file systems.

syzkaller improvements

[last updated: 2020-03-04]

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:

• Extend syzkaller's FreeBSD system call descriptions. For each system call, syzkaller requires a set of annotations that describe the system call's arguments. It is missing many of FreeBSD's system calls. syzkaller similarly needs to be taught about device-specific ioctls.
• Support fuzzing of FreeBSD's Linux system call compatibility layer. Since syzkaller can of course fuzz Linux natively, it should be straightforward to run a Linux fuzzer on FreeBSD.
• Support external injection of USB traffic.
• Support running the fuzzer in a jail, optionally with various resource limits in place.
• Test syzkaller with a ZFS root filesystem instead of UFS. Work with the syzkaller developers to get a FreeBSD+ZFS target running in syzbot.

• Port support for automated patch testing and crash bisection to FreeBSD. Some details are listed here.

• Work with the project mentor to triage and possibly fix any kernel bugs found in the process.

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

[last updated: 2020-03-02]

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.

Tools

NanoBSD Reimagined

[last updated: 2026-01-23]

NanoBSD is a tool used to create customized FreeBSD system images that are suitable for use on USB keys, memory cards, or other mass storage media. It was developed over 20 years ago, and while it has been maintained, there are many ways it can be modernized and improved.

Potential Improvements:

• Creating images entirely from packages rather than building from source
• Adding support for ZFS to harness workflows around boot environments, snapshots, and clones
• Researching and potentially adding or improving integration with tools such as mtree, makefs, mkimage, and possibly poudriere
• Ensuring "tier 1" support for aarch64
• Adding support for UEFI booting
• Adding support for gpart partitioning
• Adding support for integrating nuageinit with embedded images

Potential Work Plan:

• Phase 1: Base Packages Integration: Update current script to optionally use pkg to install a minimal world, use makefs to turn it into a bootable UEFI image.
• Phase 2: Hardware/Arch: Ensure the image boots on aarch64. This would be a Mid-term Deliverable.
• Phase 3: ZFS and Logic: Implement ZFS pool creation and basic snapshot logic for "updates."
• Phase 4: Documentation: Cleanup and extend documentation.

Not all of these tasks can be completed within a single GSoC project. Any project would have to prioritize a subset of potential improvements.

Improve LLDB on FreeBSD

[last updated: 2026-01-23]

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

1. Better kernel crash dump information

When loading a kernel core lldb just reports e.g. "Core file '/var/crash/vmcore.7' (x86_64) was loaded." We ought to select the appropriate thread when possible (e.g., the thread that panicked) and print the kernel message buffer from the core file. See notes in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283190 for an example of the output we get, and a reference to the developer handbook chapter showing what kgdb (GNU debugger) emits.

2. 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:

• Enable Lua bindings to create new LLDB commands
• Generate Lua documentation similar to the Python documentation
• Write a tutorial for scripting LLDB with Lua

• Add convenience methods to support common FreeBSD kernel debugging tasks from Lua, such as those described in https://freebsdfoundation.org/wp-content/uploads/2019/01/Debugging-the-FreeBSD-Kernel.pdf

3. 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).

Raw Ideas

Warner Losh maintains a list of quick ideas that are little more than 'one liners' at Warner's Crazy Idea Page. This page requires more work than the ideas listed above. They would fit into small project category, especially for someone new to FreeBSD that wants to do a specific programming task to learn about the system. However, these ideas also require more planning on the part of the student than the ideas listed above, but could also be a better fit for some student's interest that aren't captured in the above ideas. The ideas are centered around lua, acpi, the boot loader, and FreeBSD's git/github integration.

To work on this:

• Join the FreeBSD discord server (invite) #kernel channel and tag me (@bsdimp).

• Explain what aspects of my crazy idea might be interesting
• We can flesh out the spec to the point it can be used to submit to GSoC.
• These ideas most likely would be in the 'small' category, though some might be too small (but don't let that stop you from reaching out)
• Not all the ideas are in the kernel: many are in the boot loader or are primarily working with lua. I just hang out on the #kernel channel since we don't have a GSoC one yet.
• Ideas don't strictly need to be on my list either: if you're inspired by the list to ask about something else, please don't hesitate to do so.

---

CategoryGsoc