FreeBSD Google Summer of Code Ideas

Below are ideas for FreeBSD GSoC which the FreeBSD community have suggested. They should be approximately 12-week of work for Summer of Code.

These are only suggestions: copy/pasting the text in your proposal doesn't guarantee we will acccept 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 12-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: SummerOfCode2019, SummerOfCode2018, SummerOfCode2017, SummerOfCode2016, SummerOfCode2015, SummerOfCode2014, SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010.

How to use this idea list

For students

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

Ideas list


Kernel Projects

Add support for building Linux-only network drivers

Mentor

Mahdi Mokhtari mmokhi@FreeBSD.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: https://wiki.freebsd.org/Devsummit/201902#DiscussionNotes


Add support for booting a Xen Dom0 from EFI

Mentor

 Roger Pau Monné royger@FreeBSD.org

Skills

C (advanced), EFI, knowledge of virtualization is a bonus

Mid-term deliverable

Have a multiboot2 implementation capable of booting Xen from the FreeBSD/EFI loader

Final deliverable

Be able to boot a FreeBSD/Xen Dom0 from EFI using the FreeBSD loader

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:

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


Kernel sanitizers

Mentor

Andrew Turner andrew@FreeBSD.org

Skills

C (intermediate), kernel(intermediate)

Mid-term deliverable

Get an initial port of the sanitizer working with FreeBSD

Final deliverable

Finish the port and use it with a kernel fuzzer to search for bugs

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

Mentor

?

Skills

C (intermediate), computer-architecture(intermediate)

Mid-term deliverable

Tests for a couple of instructions

Final deliverable

Set of automated tests for all instructions

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

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.


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

Mentor

Giuseppe Lettieri giuseppe.lettieri@unipi.it

Skills

C (advanced), knownledge of the kernel networking subsystem

Mid-term deliverable

Mechanism to intercept outgoing packets and divert them to one or more dispatcher kthreads (no scheduling)

Final deliverable

Integration with dummynet to have one of the kernel threads to perform packet scheduling

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

Mentor

Giuseppe Lettieri giuseppe.lettieri@unipi.it

Skills

C (advanced), knownledge of virtualization technologies

Mid-term deliverable

Add an abstraction layer inside QEMU towards hardware acceleration functionalities (currently KVM)

Final deliverable

Extend libvmm to match the same functionalities that KVM offers to QEMU on Linux

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

Mentor

 Warner Losh imp@FreeBSD.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 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.


Userland projects

IPv6 Userland Cleanup

Mentor

TBD

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Have at least rpc.statd and rpc.quotad work over IPv6

Final deliverable

Have more tools work over IPv6

Description

Several userland network utilities do not work correctly with IPv6.

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:


Dual-stack ping(1) command

Mentor

 ?

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Version of "ping" with basic functionality for both v4 and v6 hosts

Final deliverable

Fully functional unified ping command, maintaining all functionality from both versions

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

Mentor

?

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Version of "traceroute" with basic functionality for both v4 and v6 hosts

Final deliverable

Fully functional unified traceroute command, maintaining all functionality from both versions

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

Mentor

Ed Maste emaste@FreeBSD.org

Skills

C (intermediate)

Mid-term deliverable

(need midterm goal)

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

Mentor

Warner Losh imp@FreeBSD.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@FreeBSD.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.


Network Configuration Libraries

Mentor

Allan Jude allanjude@freebsd.org

Co-Mentor

kp@

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:


Testing

Add more FreeBSD testing to Xen osstest

Mentor

Roger Pau Monné royger@FreeBSD.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.


Integration testing for the netmap subsystem

Mentor

Giuseppe Lettieri giuseppe.lettieri@unipi.it

Skills

C (advanced), knownledge of the netmap subsystem

Mid-term deliverable

A scriptable library that allows to access all of the netmap control and data transfer APIs

Final deliverable

A set of positive and negative test scripts that cover the whole API

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

Mentor

Amazing Subject Matter Expert - manu@ ?

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

thj@

Co-mentor

kp@

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

Allan Jude allanjude@

Co-Mentor

Roger Pau Monné royger@FreeBSD.org

Co-mentor

Brad Davis??

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


SummerOfCodeIdeas (last edited 2019-05-16 20:53:25 by BrooksDavis)