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: SummerOfCode2017, SummerOfCode2016, SummerOfCode2015, SummerOfCode2014, SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010.

For students

For mentors

Skill levels

List of ideas

Ideas list


FreeBSD/Xen: import the grant-table bus_dma(9) handlers from OpenBSD

Mentor

 Roger Pau Monné royger@FreeBSD.org

Skills

C (advanced), knowledge of virtualization is a bonus

Mid-term deliverable

Have a Xen-specific implementation of bus_dma(9) in order to map and share grants with domains

Final deliverable

Have the interface fully integrated with all the frontends and backends present in FreeBSD

Description

In order to implement Xen paravirtualized drivers, an abstract reference to memory pages is used. This mechanism is called grant references and are used in order to exchange information in a safe way between Xen domains. This interface is also extensively used by Xen paravirtualized IO drivers, and it's current implementation in FreeBSD is lacking a proper integration with the rest of the system. OpenBSD has integrated grant references into it's bus_dma(9) subsystem, allowing Xen drivers to use a more transparent integration with the rest of the OS. The aim of this project is to bring the OpenBSD bus_dma(9) grant table handlers from OpenBSD into FreeBSD, expand them in order to support all the grant operations (share and map), and modify the existing frontends and backend in FreeBSD in order to make use of them.

The OpenBSD implementation can be found in src/sys/dev/pv/xen.c and a talk about it at Implementation of Xen PVHVM drivers in OpenBSD


Add support for usbdump file-format to wireshark and vusb-analyzer

Technical Contact: hselasky@

Currently it is not possible to graphically see USB traffic. By adding a backend to the above mentioned software packages this can easily be made possible.

The project consists of writing a small amount of C (wireshark) and Python (vusb-analyzer) code.

This is expected to be a 1 month exercise.

Requirements


Write a new boot environment manager

Mentor

Allan Jude allanjude@

Co-mentor

??

Skills

C (intermediate)

Mid-term deliverable

a tool to create and manage boot environments

Final deliverable

a replacement for sysutils/beadm

Description

Create a replacement for sysutils/beadm

A boot environment (BE) is a ZFS file system that is designated for booting. You can maintain multiple boot environments on a single system.

Generally, new boot environments are creating by doing a copy-on-write clone of the existing boot environment, before performing destructive procedures such as an upgrade. If the procedure fails, the operator can select the previously working boot environment from the boot menu. Other system directories, such as /usr/home are created as separate filesystems, so changes made there are not lost when booting from a previous boot environment.

chroot, and jail support, to test a BE before booting into it.


Basic smoke test of all base utilities

Mentor

Brooks Davis brooks@

Co-mentor

??

Skills

C (beginner)

Mid-term deliverable

test the basic functionality of a few utilities

Final deliverable

test the basic functionality of all utilities

Description

Many of the 700+ programs in FreeBSD have no test coverage at all. This particularly problematic when toolchain and system runtime components are updated.

This project aims to create new test infrastructure and automation tools to add trivial tests (i.e. running tool -h or tool --version) to verify that the program is linked properly. Ideally, the tests to add for each program should be detected by a script the parses manpages or runs tools experimentally.


Port OpenBSD's pf testing framework and tests

Mentor

Kristof Provost kp@

Co-mentor

Ermal Luci eri@

Skills

C (intermediate), kernel(intermediate), network(intermediate)

Mid-term deliverable

pfctl parser tests

Final deliverable

network tests

Description

OpenBSD has a number of tests for both the rule parser, and the firewall (using virtualisation).


Userspace Address Space Annotation

Mentor

Brooks Davis brooks@

Co-mentor

Pedro Giffuni pfg@

Skills

C (advanced), kernel(intermediate)

Mid-term deliverable

Integrate the sparse tool with kernel build

Final deliverable

Annotate an appreciable portion of system calls with userspace annotations and validate them with sparse

Description

The Sparse tool allows pointers to be annotated as belonging different address spaces. This is useful in the kernel where user program addresses require special handling (via copyin, copyout, etc) and likewise memory mapped device addresses may require special handling. We would like to annotate userspace pointers arriving from system calls to avoid mistaking such pointers for kernel pointers. In addition to preventing crashes, the discipline of annotating pointers as being userspace pointers paves the way for memory safety implemented by systems like CHERI.

https://sparse.wiki.kernel.org/index.php/Main_Page


zstandard integration in libstand

Mentor

Allan Jude allanjude@

Co-mentor

Baptiste Daroussin bapt@

Skills

C (intermediate, network(beginner), security(intermediate)

Mid-term deliverable

Add libzstd to libstand

Final deliverable

Capsicumized frontend for zstd

Description

ZStandard (zstd) is a new compression algorithm by the creator of lz4. It offers similar or better compression than gzip, but at much faster compression and decompression speeds.

Adding zstd to libstand to allow decompressing zstd compressed kernel and mfsroot images, augmenting existing lzma and gzip support.

These better compressed, and fast to decompress images will increase performance for network-booted diskless FreeBSD instances.

An additional goal of this project is to provide a capsicum sandboxed version of the zstd frontend (with gzip like syntax).


Replace mergesort implementation

Mentor

Brooks David brooks@

Skills

C (intermediate)

Mid-term deliverable

A replacement implementation

Final deliverable

Benchmarks showing the new implementation is better

Description

Replace mergesort() in libc with a new or existing BSD licensed implementation.

The existing implementation has a limitation such that it cannot sort values smaller than half the size of a pointer (e.g. char's or on 64-bit systems shorts). This makes it unsuitable as a replacement for qsort() and heapsort() and renders it useless on systems with larger pointer sizes.

Write or import a benchmark to validate the performance of the replacement. Perform profiling with gprof(1), pmcstat(8) and/or DTrace.

Improve the existing tests.


Test Kload (kexec for FreeBSD)

Mentor

??

Co-mentor

??

Skills

C (intermediate), kernel(intermediate), computer-architecture(intermediate)

Mid-term deliverable

kload is tested and working

Final deliverable

develop a testing framework for kload

Description

https://wiki.freebsd.org/Kload

It's like Linux kexec feature, lets you restart the OS very quickly without going via BIOS initialization. You pass the ELF file of the kernel and the current kernel gets overwritten and the new kernel starts.

Requires a great deal of testing

Requirements


Kernel fuzzing suite

Mentor

??

Co-mentor

??

Skills

C (intermediate), kernel(intermediate)

Mid-term deliverable

Get a fuzzing tool working

Final deliverable

Fuzz test the FreeBSD Kernel

Description

FreeBSD's memguard(9), and the compiler stack protection offer a good framework to detect memory leaks and buffer overflows in the kernel and the complete OS is frequently checked with static analysis tools, but we lack kernel specific fuzzer testing tools to aid in such detection. Originally the linux Trinity fuzzer was the main example of such tool, Dmitry Vyukov's syzkaller is somewhat more promising, and as of lately there is also the TriForceAFL used for OpenBSD.

A native tool would be good but perhaps just running the Trinity tool under the linux emulator, along with memguard(9), would reveal general bugs in the kernel.


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


NVMe controller emulation for bhyve

Mentor

??

Co-mentor

Peter Grehan grehan@freebsd.org

Skills

C (intermediate), computer-architecture(intermediate)

Mid-term deliverable

FreeBSD guest can recognize NVMe device

Final deliverable

Linux/Windows/FreeBSD guests can transfer data

Description

NVM Express (NVMe) is a standard for accessing high-speed flash storage over PCIe.

An NVMe controller emulation for bhyve would offer a higher performance storage solution for Windows guests compared to AHCI/virtio-block, and would also offer a useful testing platform for future storage development.

The emulation doesn't have to be fully spec-compliant, but in the style of other bhyve device emulations, should have enough functionality to be useable by a number of guest operating systems, in particular recent Linux, Windows and FreeBSD.


Verification of bhyve's instruction emulation

Mentor

??

Co-mentor

Peter Grehan grehan@freebsd.org

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

Tycho Nightingale tychon@freebsd.org

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


audit framework test suite

Mentor

George Neville-Neil gnn@freebsd.org

Co-mentor

Robert Watson

Skills

Python or similar (intermediate), Basic understanding of C

Mid-term deliverable

Tests for a small set of audit tracepoints integrated into Kyua framework

Final deliverable

Set of automated tests for a all audit tracepoints

Description

FreeBSD's audit(4) system is a widely used security mechanism for auditing access to the operating system kernel and its facilities, including storage and networking. Although the audit framework itself is quite mature, and is used outside of FreeBSD, notably on Mac OS and related products, it is in need of a set of automated tests so that it can be reliably extended with minimal risk of the introduction of security regressions.

On this project students will learn about computer systems security as well as how security mechanisms are implemented in a production operating system. The ideal student for this project is one who is interested in learning about computer security and security mechanisms permeate the system in a broad way, touching on every service provided by the operating system, including processes, file systems, networking etc.


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.


Lua in bootloader

Mentor

[[EmmanuelVadot|@manu@freebsd.org]

Co-mentor

??

Skills

C (intermediate) Lua (intermediata)

Mid-term deliverable

Test/fix the existing branch

Final deliverable

Finish integration into the project

Description

We have a branch (https://svnweb.freebsd.org/base/projects/lua-bootloader/) with some code on bringing lua instead of forth into he bootloader.

Most of the work has been done previously and all what's left is testing and fixing things that doesn't work.

On the Mid-term we expect to have the code staging in the branch "mergeable".

On the Final deliverable we expect to have something that can fully replace the already-existing forth implementation (i.e. Boot Environment etc ...)


POSIX compliance testing framework

Mentor

pfg@

Co-mentor

standards@

Skills

C (intermediate) , kernel(intermediate), UNIX(advanced, intermediate)

Mid-term deliverable

TOG Testing framework available as ports

Final deliverable

Sustainable testing and bug reports

Description

Standards compliance has always been one of the main objectives for the FreeBSD project. In the past we had some efforts to follow regular testing procdures but we haven't followed up the efforts with proper and sustainable infrastructure. The Open Group has made some testsuites available freely. In particular the FreeBSD port of Tet testing suite should be rescued and the Linux lsb-vsx testuite should be cleaned up so that we are able to do regular testing on both linux-emulation and FreeBSD-native support. Any compliance issue should be reported in bugzilla and an attempt to contact the respective group should be made to draw a plan towards compliance.


coreclr: add Microsoft's coreclr and corefx to the Ports tree.

Mentor

ports@

Co-mentor

hackers@

Skills

C ( intermediate), Ports (intermediate)

Mid-term deliverable

Ports for the base .Net support available

Final deliverable

Port Microsoft's Powershell

Description

There has already been porting work on getting the .Net implementation to run on FreeBSD, including build bots, however it is not quite bootstrapable as yet. Full support for this is important and we don't want to stop there but also bring Microsoft's PowerShell.

SummerOfCodeIdeas (last edited 2017-05-05 20:33:05 by PedroGiffuni)