FreeBSD Google Summer of Code Ideas

Below are ideas for FreeBSD GSoC which the FreeBSD community have suggested. They fit roughly into the GSoC timeline but mentors and students need to work together to make sure that the project can reasonably be completed in time.

These are only suggestions: copy/pasting the text in your proposal doesn't guarantee we will accept it. You can propose ANY FreeBSD-related idea/project you want but we want to see that you have researched the project and that you have a clear plan. We like original ideas, since we know you'll be most interested in working on something you came up with and are passionate about. Remember this must be a 10-week project and we want to see some schedule.

It is especially important that Summer of Code applicants contact idea owners or suitable mentors early so that they can get feedback during the application process, and that the project can reasonably be completed in the GSoC timeframe. For projects where no mentor is listed, or for project proposals created by students, we recommend you try to contact committers working in the area and discuss the project with them. Please add '@FreeBSD.org' to any email address listed in the form gavin@. If you are unsure who to contact, please see the SummerOfCodeContacts page.

We also have a generic FreeBSD ideas page at IdeasPage and WantedPorts. Note that many of these may not be suitable Summer of Code projects as-is, but may provide inspiration for ideas of your own. The projects listed on this page are not restricted to GSoC participants, of course.

For a feel for projects from previous years, visit: SummerOfCode2020, SummerOfCode2019, SummerOfCode2018, SummerOfCode2017, SummerOfCode2016, SummerOfCode2015, SummerOfCode2014, SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010.

How to use this idea list

For students

Skill levels

GSOC projects this year run for 10 weeks, with 18-20 hours of work per week. Note that this is a departure from previous years, where projects ran for 12 weeks at 30 hours per week. Choose a project you feel you can realistically do within the timeline. If you feel unsure, please contact the listed mentor(s) to get their opinion on how much effort and experience a given project may require.

Ideas list


Kernel Projects

Add support for building Linux-only network drivers

Mentor

Mahdi Mokhtari <mmokhi AT FreeBSD DOT org>

Skills

C (intermediate), Kernel (intermediate), Network

Mid-term deliverable

Have netlink base functionalities working

Final deliverable

Be able to build a sample Linux-only network driver (Freifunk?) for FreeBSD

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)

Further info is available here.


VGA emulation improvements for bhyve

Mentor

?

Skills

C (intermediate), computer-architecture(intermediate)

Mid-term deliverable

Performance improvement in text mode for FreeBSD guests

Final deliverable

Text and VESA modes tested against different guest o/s's

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.


bhyve debug server enhancements

Mentor

John Baldwin <jhb AT FreeBSD DOT org>

Skills

C (advanced), kernel programming (advanced)

Description

With r333140 bhyve implements a debug server, allowing debuggers that speak the GDB protocol to inspect guest state. r355724 extended the debug server to support the setting of breakpoints. Some more features that would be useful:

* The breakpoint implementation uses an Intel-specific feature, the Monitor Trap Flag, to perform single-stepping, but this does not work on AMD systems. It should be possible to make use of the RFLAGS.TF flag to perform single-stepping if the monitor trap flag is not implemented. Note that this could be implemented and tested on Intel systems by disabling the use of monitor traps in the debug server.

* Implement support for hardware watchpoints. In particular, modify the debug server to set debug registers in the guest and handle VM exits due to debugging exceptions. Some care would be needed to avoid clobbering guest state if the guest OS is making use of hardware debug registers.

Note: these projects require familiarity with at least the basics of how debuggers and hardware-assisted hypervisors work.


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

Mentor

Warner Losh <imp AT FreeBSD DOT org>

Skills

C (intermediate), knowledge of kernel build a plus

Mid-term deliverable

First 2/3 of drivers converted, preliminary GENERIC pruning for 1 board that boots with drivers loading

Final deliverable

All drivers converted, armv7 GENERIC pruned, booting on multiple boards with drivers loading at boot as needed

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.


Finishing MPLS implementation

Mentor

TBD

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

All mandatory requierement listed here

Final deliverable

Full integration with net/frr LDP daemon and/or net/bird

Description

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

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.


Linuxulator on powerpc64

Mentor

Justin Hibbits <jhibbits AT FreeBSD DOT org>, Brandon Bergren <bdragon AT FreeBSD DOT org>

Skills

C, kernel

Mid-term deliverable

TBD

Final deliverable

TBD

Description

FreeBSD's Linux compatibility layer, Linuxulator, currently supports ARM and x86. This project is to add support for powerpc64, at least preliminary support. At a minimum simple static binaries should work from this project.


eBPF XDP Hooks

Mentor

Ryan Stone <rstone AT FreeBSD DOT org>, Alexander Chernikov <melifaro AT FreeBSD DOT org>

Skills

C (intermediate), Kernel (intermediate)

Mid-term deliverable

Ability to load and execute eBPF program in a single network driver's receive path that can pass or drop packets

Final deliverable

Implement XDP_TX and XDP_REDIRECT commands. Implement eBPF helper functions and maps required to perform simple filtering.

Description

The eBPF eXpress Data Path (XDP) allows eBPF programs to be run to filter received packets as early as possible, avoiding unnecessary processing overhead before the filter is run. The goal of this project is to extend an existing FreeBSD network driver (a virtual NIC like a VirtIO if_vtnet would be fine) to be able to call into an eBPF program when processing a newly received packet. As in XDP, the driver must PASS (accept and process normally), DROP, TX or REDIRECT the packet as specified by the program. eBPF helper functions and maps for aiding in packet filtering will also need to be implemented.


eBPF Tracing Hooks

Mentor

Ryan Stone <rstone AT FreeBSD DOT org>

Skills

C (intermediate), Kernel (intermediate)

Mid-term deliverable

Ability to load eBPF program against SDT hook and execute the program when the hook fires

Final deliverable

Implement helper functions and map types for tracing kernel execution.

Description

The FreeBSD kernel has Statically Defined Tracing (SDT) probe points which are used as entry points for tracing the kernel via DTrace. The goal of this project is to allow these tracing points to also be able to call into eBPF programs. The first stage of this project is to extend the existing SDT infrastructure to allow eBPF programs to be attached to probes. The second stage is to implement eBPF helper functions and maps necessary for tracing kernel execution. This could include eBPF stacktrace and histogram maps, as well as helper functions to get the current time, current thread, current CPU, etc.


eBPF JIT for arm64

Mentor

Ryan Stone <rstone AT FreeBSD DOT org>

Skills

C (intermediate), arm64 assembly (advanced)

Mid-term deliverable

JIT eBPF arithmetic and flow control instructions to arm64 assembly

Final deliverable

JIT all eBPF instructions to arm64 assembly

Description

A just-in-time compiler for eBPF targetting amd64 (x64-64) instructions is in progress. The goal of this project is to extend the JIT to also compile to arm64 instructions.


Mentor

Alexander Chernikov <melifaro AT FreeBSD DOT org>, Mahdi Mokhtari <mmokhi AT FreeBSD DOT org>

Skills

C (intermediate), Kernel (intermediate)

Mid-term deliverable

able to setup AF_NETLINK sockets and pass a request to the routing subsystem (NETLINK_ROUTE)

Final deliverable

Routing daemon of choice (bird,frr,..) is able to interact with kernel routing subsystem via netlink. implement another netlink family, preferrably NETLINK_KOBJECT_UEVENT

Description

Netlink is widely used in linux for many network-related kernel<>userspace communications. Many apps require kernel netlink support to work, making them hard to port to FreeBSD. The goal of this project is to add Netlink support to FreeBSD kernel for route and notification protocol families.


Unified kernel tracing interface

Mentor

Mark Johnston <markj AT FreeBSD DOT org>

Skills

C (advanced), Kernel

Mid-term deliverable

Implementation available for amd64

Final deliverable

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.


Add audit(4) support to NFS

Mentor

TBD

Skills

C (intermediate), Kernel (intermediate), Security (intermediate)

Mid-term deliverable

Ability to generate an audit trail for any NFSv3 RPC

Final deliverable

Ability to generate an audit trail for any NFS RPCs

Description

Security Event Audit is a facility to provide fine-grained, configurable logging of security-relevant events, and is intended to meet the requirements of the Common Criteria (CC) Common Access Protection Profile (CAPP) evaluation. It can record an audit record for various events, such as process creation, network activity, or file system activity. However, it mostly works at the syscall level. Since the NFS server is implemented within the kernel, that means NFS RPCs don't generate any audit records. audit(4) can still be used within NFS networks, but auditd must be run on every NFS client. It would be a great addition if each NFS RPC could be audited. That would allow auditd(8) to run just on the NFS server, and still audit all NFS activity within the network.


Port squashfuse to the FreeBSD kernel

Mentor

Ed Maste <emaste AT FreeBSD DOT org>

Skills

C (expert), fusefs (expert), kernel

Mid-term deliverable

Basic squashfs.ko functionality available with mount(8)

Final deliverable

MFSBSD support

Description

squashfs is a read-only filesystem targeted for small embedded environments, where memory and disk space is constrained. squashfuse is a BSD-licensed FUSE implementation of squashfs. The project would be to port this implementation to the FreeBSD kernel, with the aim of being able to boot FreeBSD from an in-memory squashfs filesystem.


OpenBSD pf port (to ports)

Mentors

Kristof Provost <kp AT FreeBSD DOT org>

Skills

kernel (intermediate)

OpenBSD's pf version has evolved significantly away from the version in FreeBSD. While a full merge is a project far beyond the scope of GSoC there is some value to a straight port.

This would involve taking the OpenBSD pf code and making it build (and work) against FreeBSD's kernel. This port is intended to live in the ports collection, not in the src tree. This means coping with the differences in kernel API between OpenBSD and FreeBSD. Ideally the required changes should be documented extensively, to easy any future porting work.

It does not need to address VNET (although that's a good stretch goal), locking improvements (a single PF mutex is acceptable) or migration tooling from the FreeBSD pf.conf syntax to the new syntax.


Command Line Editing, history and escape completion in Boot Loader

Mentors

Warner Losh <imp AT FreeBSD DOT org>

Skills

C and Lua

The current boot loader lacks any kind of command history and editing at all. This is because it was designed to be small. Now that UEFI has greatly expanded the limits, it makes sense to bring in functionality like this.

This effort would involve creating a number of primitives for expansion, storing the history, etc. It would likely also require some lua integration to work.

This project is one that has a lot of sub-parts, some of which may be omitted (eg command history w/o filename completion) and still result in good project.


Userland projects

IPv6 support and cleanup of address family dependency in userland utilities

Mentor

Hiroki Sato <hrs AT FreeBSD DOT org>

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

?

Final deliverable

?

Description

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:


Port SGI's XFS Filesystem to fusefs

Mentor

Pedro Giffuni <pfg AT FreeBSD DOT org>

Skills

C (intermediate), fusefs (intermediate)

Mid-term deliverable

Skeleton fusefs module and XFSprogs

Final deliverable

XFS fusefs module with read support ready for the ports tree

Description

SGI open-sourced their production Journaled File System, used in IRIX, and ported it to the linux kernel. The design was quite revolutionary for its time and had many interesting features. At a time, there was great interest for a FreeBSD native port and up to FreeBSD 9 there was even an initial port with read-only support, but eventually the complexity and restrictive licensing killed the port altogether. SGI has disappeared now but in linux the filesystem is still widely used and developed by Redhat. While there are some options (https://www.freshports.org/sysutils/fusefs-lkl/lkl, https://sourceforge.net/projects/fusexfs/fuse-xfs) to access XFS, a clean FreeBSD userland implementation that could perhaps use the advantages of the existing code would be useful to compensate for the absence of a kernel version.

Any proposal must include a coding plan showing understanding of the APIs involved and a test plan.


UFS4fuse: support FreeBSD's UFS2 with fusefs

Mentor

Pedro Giffuni <pfg AT FreeBSD DOT org>

Skills

C (expert), fusefs (expert)

Mid-term deliverable

Read-only support for userland

Final deliverable

Fully functional UFS with basic read and write support

Description

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++ constructs would be interesting.

This project is challenging: any proposal must include a coding plan and should include credible evidence of userland filesystem development.


ELFToolChain improvements

Mentor

Ed Maste <emaste AT FreeBSD DOT org>

Skills

C (intermediate)

Mid-term deliverable

LLVM bytecode support for ar/nm/ranlib

Final deliverable

(need final goal)

Description

The elftoolchain project provides FreeBSD with several commands for handling ELF executables, including "ar", "addr2line", "elfdump", "nm", "strings", amongst others. These replaced the equivalent tools from GNU binutils. One useful project, needed to support LLVM's Link-Time-Optimization, would be to extend ar, ranlib and nm to support archive files containing LLVM bitcode files. These files have their own container format; the project would involve adding a small parser that is sufficient to extract information required by these tools (e.g., the symbol table).

Another potential project would be to investigate the GNU binutils test suites for these tools and attempt to run them using the ELFToolChain equivalents, with the aim of finding and fixing bugs and incompatibilities.


Move to GENERIC armv7 distribution scripting

Mentor

Warner Losh <imp AT FreeBSD DOT org>

Skills

Shell / Make (intermediate)

Mid-term deliverable

release scripts working, u-boot ports updated

Final deliverable

User tool

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

Mentor

Warner Losh <imp AT FreeBSD DOT org>

Skills

Shell / Make (intermediate)

Mid-term deliverable

scripts to mine u-boot ports and screen mock-ups

Final deliverable

Web tool working

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.


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

Final deliverable

Sandbox the complete list of target applications

Description

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

Kristof Provost <kp AT FreeBSD DOT org>

Co-Mentor

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

Final deliverable

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

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:


syzkaller improvements

Mentors

Andrew Turner <andrew AT FreeBSD DOT org>, Mark Johnston <markj AT FreeBSD DOT org>

Skills

golang (intermediate), kernel (intermediate)

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.


Testing

Add more FreeBSD testing to Xen osstest

Mentor

Roger Pau Monné <royger AT FreeBSD DOT org>

Co-mentor

Ian Jackson <ian.jackson AT eu.citrix DOT com>

Skills

Perl and shell (to write tests for osstest), FreeBSD system administration: pxe install, complete setup, build from sources, generate installer media

Mid-term deliverable

osstest should be able to setup a FreeBSD bare-metal box and automatically generate the installer media to setup itself

Final deliverable

osstest should be able to compile Xen on FreeBSD, generate guest install media and test it automatically

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.


Audit Base for Read-Only and NFS Mount Compatibility

Mentor

Amazing Subject Matter Expert - <manu AT FreeBSD DOT org> ?

Skills

/bin/sh (moderate), System and Network configuration, sqlite, berkelydb and similar (moderate), hier(7) and general FreeBSD base awareness

Mid-term deliverable

Identification of in-base components that are r/o|NFS incompatible

Final deliverable

Report on the nature of each incompatibility, ideally with proposed solutions. Kyua test suite modules for each issue identified

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

Mentor

Tom Jones <thj AT FreeBSD DOT org>

Co-mentor

Kristof Provost <kp AT FreeBSD DOT org>

Skills

/bin/sh (moderate), System and Network configuration, firewall configuration

Mid-term deliverable

Final deliverable

Test suite for firewall functionality, usable on all three firewall

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

Mentor

Brad Davis <brd AT freebsd DOT org>

Co-Mentor

Roger Pau Monné <royger AT FreeBSD DOT org>

Skills

C (beginner), make (intermediate), shell (intermediate)

Mid-term deliverable

'make release' will build MFSBSD

Final deliverable

Completed integration so all new releases of FreeBSD will include mfsbsd media

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



CategoryGsoc

SummerOfCodeIdeas (last edited 2021-04-26T02:19:16+0000 by JethroNederhof)