FreeBSD Google Summer of Code 2014

The FreeBSD Project is pleased to participate in the Google Summer of Code 2014 program.

Application

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

These are only suggestion. You can propose ANY FreeBSD idea/project you want. We like original ideas, since we know you'll be mostly interested in working on something you came up with and are passionate about. Remember this must be a 12-week project.

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. 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: SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010.

For mentors

For students

Skill levels

List of ideas

Contents

  1. FreeBSD Google Summer of Code 2014
    1. Machine readable output from userland utilities
    2. Port FreeBSD on a smartphone (any maker and model)
    3. MicroBlaze, NIOS, OpenRISC bring up
    4. TEST-o-steron for FreeBSD (node.js/Lua)
    5. CON-tinuous INtegration for FreeBSD aka improved TinderBox (node.js/Lua)
    6. PowerPC, ARM, MIPS bring-up
    7. Overhaul the config system
    8. Overhaul the config system (with Lua)
    9. RTOS/FreeBSD blend: 2 operating systems working together
    10. FreeBSD WWW Community Portal -- http://freebsd.io/ (node.js)
    11. Port NetBSD's UDF implementation
    12. CPU online/offline project
    13. Interactive Splash Screen
    14. Update Ficl in the bootloader
    15. Port FreeBSD loader to Lua
    16. Add USB target mode driver based on CTL
    17. Add CD-ROM emulation to CTL
    18. bhyve and x86/iommu integration
    19. Instruction caching for bhyve
    20. Intel e1000 device model in userspace for bhyve
    21. bhyve in-kernel timer emulations
    22. USB device model in userspace for bhyve
    23. Implement new Xen netfront/netback features
    24. USB Front-End Driver
    25. SCSI Front-End Driver
    26. VirtualBox shared folder support for FreeBSD guests
    27. Ethernet Ring Protection Switching
    28. Multiqueue BPF support and other BPF features
    29. TCP/IP regression test suite
    30. ng_aiccu (Sixxs IPv6 tunnel broker aiccu netgraph node)
    31. A New Audit Parsing API
    32. Linux to BSM Conversion Tool
    33. Capsicum application adaptation and core libraries
    34. Unattended encrypted kernel crash dumps
    35. KDE front-ends to the freebsd-update(8)utility
    36. IPv6 User Land Cleanup
    37. Use CTF data for libkvm
    38. Libprocstat and libnetstat
    39. Improve Wine support in FreeBSD
    40. BSNMP enhancements
    41. Port TrueCrypt as a geom_gate userland disk device implementation
    42. Userspace pthread mutex lock contention profiling and lock order verification tool
    43. FreeBSD port of NetworkManager
    44. Fix FreeBSD support in GNOME's system-tools-backends
    45. Finish support for compilation of i386 binaries on amd64
    46. Improve webcamd support
    47. Improve Collation and Multibyte Support in Libc
    48. Teaching DDB to speak CTF
    49. Mandatory Access Control
    50. Path-based file system MAC policy
    51. Security regression tests
    52. kgdb support for devel/gdb port
    53. kernel debugging support for LLDB
    54. High-speed firewall: convert IPFW/PF/Your-Firewall rules to C module
    55. Pluggable repository support for pkg(8)
    56. Memory compression and deduplication
    57. Implement KDBUS
    58. Port old-style regression tests to ATF
    59. Flexible dependency support for pkg(8)
  2. Submitted over WWW form, need review
    1. Task name*: Implement direct boot from ZFS pool on a GELI encrypted device
    2. Task name*: Unified ping and ping6
    3. Task name*: Unified traceroute and traceroute6
    4. Task name*: FreeBSD preseed installation (PXE)
    5. Task name*: Port kdbus, udev, and systemd
    6. Task name*: Implement CGroups or similar
    7. Task name*: implement Intel Supervisor mode access prevention and bootime
    8. Task name*: Improve debugging capabilities of RC startup scripts
    9. Task name*: Fast Reroute with quagga and FreeBSD
    10. Task name*: Dragonfly Mail Agent Cleanup
    11. Task name*: FreeBSD ZWave implementation
    12. Task name*: Support for Google Chromebook
    13. Task name*: FreeBSD Kernel FULL_PREEMPTION
    14. Task name*: FreeBSD NTPD replacement
    15. Task name*: FreeBSD Installation on air-gapped systems

Ideas list

Machine readable output from userland utilities

Mentor

alfred@

Co-mentor

eadler@

Skills

C(intermediate)

Mid-term deliverable

Convert the utilities sysctl, ifconfig, netstat, iostat, vmstat to emit one of JSON, XML, or YAML.

Final deliverable

Modify programs to emit any format based on a shared library.

Description

The output of many commands is intended to be read by humans. An unfortunate consequence is that machine parsing of these utilities is difficult and time consuming. The unfortunate effect is that retrieving most infomration requires either complex scripting and regular expressions, or it requires coding C directly to the system calls.

This proposal aims to fix that by providing an interface for userland utilities to emit machine readable output which can be easily parsed by other software components.

Commercial vendors have been modifying FreeBSD for many years to emit machine readable (XML/JSON/YAML) output for common commands to aid scripting against their implementations. A noteable example is JUNOS from Juniper Networking.

What we would do is leverage an existing library for emiting the most commmon scalar types (string, integer, float, array) and modify base FreeBSD utilities to call a library emit XML, JSON or YAML as opposed to directly calling printf.

Utilities we will tackle include:

Requirements:


Port FreeBSD on a smartphone (any maker and model)

Mentor

Wojciech A. Koszek wkoszek@

Skills

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

Mid-term deliverable

FreeBSD boots the single user-mode on the smartphone / emulator.

Final deliverable

FreeBSD has basic graphics driver and something is displayed on the display / emulator.

Description

We're living in a smart-phone era, where there are no conventional, single-function phones sold. Every phone nowadays is a fully-featured computer, sometimes outperforming laptops from 2-3 years ago. Smart-phones are fully Internet-capable, and they have tremendous importance in the nowadays technology. For FreeBSD to participate in the smart-phone revolution, it'd be really good if we could run it on the smartphone. There's a large number of specialized military grade solutions, where having a full control over the OS and the full software stack would be very good.

This is R&D task -- it'd require research into what's the most convenient solution for porting an OS to the smartphone. It can be smart-phone itself, in which case a student will probably have to have a device. Another option is using an emulator. IDE of Android comes with an emulator, so the question would be on how hard it is to run alternative OS (FreeBSD instead of the Android) into it.

Then user would have to port FreeBSD to this platform. First kernel would have to be ported. After having the kernel boot, world (applications) should probably get loaded from the network. It'd require research on whether there are any ways to do this. In case it's impossible, user would have to try to craft an image and upload it to phone's flash.

Advised would be to pick an older smartphone which has a CPU which is already supported by FreeBSD. Then the amount of work is decreased.

Student would deliver scripts and programs necessary to craft smart-phone flash image. Tools should be able to run on FreeBSD and be able to re-create an environment for booting FreeBSD on a smartphone. Additional code should be delivered for any changes to FreeBSD which require to actually boot the kernel and use the applications.

In the perfect case there'd be some time left to implement display driver.


MicroBlaze, NIOS, OpenRISC bring up

Mentor

Wojciech A. Koszek wkoszek@ (FPGA-related ideas)

Co-mentor

imp@

Skills

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

Mid-term deliverable

For MicroBlaze/NIOS/OpenRISC: FreeBSD kernel that compiles. For others: must boot and print stuff on UART

Final deliverable

For MicroBlaze/NIOS/OpenRISC: print something on UART. For others: reach driver execution

Description

MicroBlaze, NIOS and OpenRISC are synthesizable CPUs which can run on FPGA chips. FPGAs are very important for embedded industry. Goal would be to make FreeBSD boot on soft-CPU modelled in FPGA. FPGA "logic design" knowledge isn't necessary. For the bring-up, QEMU can be used.

QEMU should already support OpenRISC and MicroBlaze. NIOS is to be investigated, but there should be a QEMU model for it somewhere.

All these ports are harder than bringing MIPS/ARM/PowerPC to FreeBSD, since toolchains aren't figured out yet. So you'll have to bring a support for basic tools. So expectation is lower here: anything that compiles is OK for mid-term. Everything that somehow boots is OK for final.


TEST-o-steron for FreeBSD (node.js/Lua)

Mentor

Wojciech A. Koszek wkoszek@

Skills

C(intermediate), scripting (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Writing programs to exercise other programs is a black magic and this R&D task is about delivering solution like that. Most of the FreeBSD, sadly speaking, is not getting tested on a regular basis and it's only the user-base who can point problems and regression of particular FreeBSD releases.

Target of this project is to change this dramatically and implement virtualized solution with its own Domain-Specific-Language for automatic exercising of FreeBSD.

This task is about evaluating, which solution would be the best for FreeBSD exercising. E.g.: BSD-Hypervisor (BHyVE) may be the fastest, Xen the most cost optimal, while QEMU the most universal. The only hint: QEMU can run ARM/MIPS/PowerPC/x86 targets, which basically covers range of platforms FreeBSD is running on.

You'd create an API for starting the VM of certain type/configuration, capturing data from the VM, typing some commands in it and obtaining results. Then the obtained results should be compared with the expected pattern.

Example 1:

var m = require("vmqemu");
var kbd = m.kbd;
var mouse = m.mouse;

m.start("arm32-zynq");

m.listen('^Login', function(data) {
         kbd.type("root");
         kbd.type(m.kbd.ENTER);
});

l0 = undef;

kbd.type("whoiam", function(data) {
         l0 = m.logstart("./login.out");
         l0.log(data);
});

l0.end();

m.type("exit", function () {

});

m.stop();

Example 2:

require "sth"
require "freebsd_after_boot"
require "remote"

m1 = remote("m1");
m2 = remote("m2");

m1.cmd("ifconfig eth0 192.168.1.1");
m2.cmd("ifconfig eth1 192.168.1.2");

lines = m1.cmd("ping 192.168.1.2");

io.print(lines);

Most of the people will offer /bin/sh or Python for this, but I suggest Javascript (node.js) or Lua. Lua because it's very small and could become a part of the base system and we could have the regression-test suite run by every commiter to qualify the build. Javascript, because it'd be very easy to bring script recording/replaying to the browser. With language like Node.js, it's possible to test many, many things, including complex things, like: multicast communication, where starting N virtual machines is necessary.

Don't limit yourself to thinking it's only VM-based environment. For this task you're an architect of the solution which could be deployed in FreeBSD cluster and where m.start() actually means poweing. It could also mean that writing RBF protocol support would let us test ready-to-use systems.


CON-tinuous INtegration for FreeBSD aka improved TinderBox (node.js/Lua)

Mentor

Wojciech A. Koszek wkoszek@

Skills

C(intermediate), scripting (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Making 1 change in FreeBSD src/ directory means possibility of breaking the code. Risk is high, since complexity is huge. FreeBSD runs on x86, PowerPC, ARM, MIPS, SPARC. We're talking thousands of lines of code to support that. Some things are already achieved by TinderBox. However Tinderbox shows only whether .c code builds. Target is to see if it's working fine. Various emulators are available: VirtualBox, Qemu, GXEmul. Taking advantage of them would let FreeBSD developers and contributors start delivering even higher quality code.

The idea would be to create an infrastructure for automatic:

It may or may not be true existing TinderBox could be extended for this purposes.

Requirements

This idea has a potential to get integrated by TEST-o-steron, since it'd could be using VMs built in the CONTI.


PowerPC, ARM, MIPS bring-up

Mentor

imp@

Co-mentor

Wojciech A. Koszek wkoszek@ (FPGA-related ideas)

Skills

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

Mid-term deliverable

For NIOS/MicroBlaze: FreeBSD kernel that compiles. For others: must boot and print stuff on UART

Final deliverable

For NIOS/MicroBlaze: print something on UART. For others: reach driver execution

Description

There's a number of PowerPC, ARM, MIPS SoCs that are in consumer grade routers, etc that have chips that are supported by FreeBSD, or nearly supported by FreeBSD. Pick one and bring FreeBSD up on it. Integrate it into the tree.

NIOS and MicroBlaze are synthesizable CPUs which can run on FPGA chips. FPGAs are very important for embedded industry. Goal would be to make FreeBSD boot on an FPGA. FPGA aren't necessary, however, to do the bring-up. QEMU can be used.

NIOS/MicroBlaze ports are harder, since toolchain isn't figured out. So expectation is lower here: anything that compiles is OK for mid-term. Everything that somehow boots is OK for final.

For PowerPC/ARM/MIPS most of the stuff (infrastructure) is done already. You just need to plug your files to the infrastructure and you're ready to start porting. Thus: for mid-term anything that boots on your hardware is OK. For final we'd expect to get to driver execution level and basically try to push it as much as possible. This will give you great PASSing score. Single-user boot is AMAZING outcome. Multi-user boot is extraordinary.


Overhaul the config system

Mentor

imp@

Co-mentor

Wojciech A. Koszek wkoszek@

Skills

C(intermediate) Scripting(intermediate), kernel(beginner)

Mid-term deliverable

YourConfig(1) that reads dependencies between kernel elements and can print it (as a dot(1) graph, YAML, json)

Final deliverable

YourConfig(1) will generate a makefile for minimal kernel on x86/amd64

Description

Right now the kernel is built twice: once for the static modules in the kernel, and once for the dynamically loaded. There's also inconsistent dependency tracking. We should fix this. Bike-shed included, along with three colors of paint. Language is up to you, but must be discussion prior starting the project--it must be something available in the base-system.


Overhaul the config system (with Lua)

Mentor

Wojciech A. Koszek wkoszek@

Co-mentor

wkoszek@

Skills

C(intermediate) Scripting(intermediate), kernel(beginner)

Mid-term deliverable

YourConfig(1) that reads .lua data file with dependencies between kernel elements and can print it (as a dot(1) graph, YAML, json) and warn if mandatory modules weren't included

Final deliverable

YourConfig(1) will generate a makefile for minimal kernel on x86/amd64

Description

Kernel config(8) program is as old as BSD. It grew lots of hacks over the years, out of which every one of them is USEFUL. However config(8) needs much more flexibility. For e.g.: ARM we have dozens of kernel configurations, and differences between them are minor. We have kernel and modules build twice -- burnt time and energy. We don't have an easy way to customize kernel builds for FreeBSD vendors. Yet, config(8) is as big as Lua source code. Lua doesn't depend on yacc/bison for parsing -- cross-building FreeBSD kernels on platforms like Linux or MacOSX (or even Windows) would be much easier.

Suggestions for a project:

Lua is what NetBSD guys are using as their Domain Specific Language. I strongly believe FreeBSD could take advantage out of it too.


RTOS/FreeBSD blend: 2 operating systems working together

Mentor

Wojciech A. Koszek wkoszek@

Skills

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

Mid-term deliverable

FreeBSD running on 1 core with trivial RTOS (counter) running on 2nd core and user-space program showing the counter of the RTOS

Final deliverable

FreeBSD running on 1 core with trivial some other Open Source RTOS of your choice. 2 OSes can communicate with each other (any example is OK)

Description

A lot of safety critical software requires RTOS or some form of RTOS-alike loop running on bare metal. For flexibility however, people pick running other general purpose operating system on 2nd core of the CPU. Basically think about developing a software solution which could be used in medical devices. Interrupt latency is critical (RTOS), but you still want to have nice UX done with Qt GUI or maybe WWW (FreeBSD).

You'll likely need to be done with computer architecture classes, and multithreading classes to approach this project, or have a strong desire to sacrifice a bit of your time to grasp this stuff.

Approach: suggested is starting from ARM-based SMP system. This project can be accomplished with Qemu emulator too (no need for custom software).

How I imagine this project done:


FreeBSD WWW Community Portal -- http://freebsd.io/ (node.js)

Mentor

Wojciech A. Koszek wkoszek@

Skills

C(beginner)

Mid-term deliverable

FB/LinkedIn login; users can store their dmesg messages online, as well as upload scripts and crash dumps, put data into their profiles and mark whether they'd like to help with development or not and to which extent

Final deliverable

Same as for mid-term + bug database

Description

This task will be about bringing new levels of integration to the FreeBSD environment and making FreeBSD look more like a high-quality product. It's based on BSD XXI Manifesto idea:

https://wiki.freebsd.org/BSD_XXI_Manifesto

You'll get a feel of what should be created after reading this document. Basically it's about creating a notion of every FreeBSD user having his "FreeBSD ID" and being able to expand the FreeBSD community far beyond of what we have now. Idea is that:

Technical aspects (aka words from the mentor). I'm interested in

For the purposes of the prototype, you can assume that using 'curl' is permitted. Basically whatever GET/POST/PUT/DELETE requests you do, do them from Curl command line API. For delivering the results, we'd assume simple /bin/sh scripts are provided and they'll call curl for testing.

It'd be nice if users could create tags of uploaded content. We'd create fixed amount of tags of certain categories (needhelp, kernel, application, crash, dumpfile, dumpphoto) and maybe couple others.

For anything that users contribute, help, submit (bug fixes, patches, bug reports), they get "Likes" or credits, which earn their way to gaining certain permissions within FreeBSD.org.

I picked node.js because this is the only technology I'm motivated enough to review the code for. You can convince me if you know anything better/are familiar with other competitive choices, however my current interest is only in node.js.

If you have any previous sites/portfolio of yours, this would be nice to see too.

By modules I meant that there's a lot of exiting node.js modules. Basically: lots of useful stuff is already there, and you'd be just tying bigger pieces together.

In terms of REST API, this is based on which feature you'd start implementing. Let's assume you'd pick something minimal, but very useful, so, as an example:

REST API for this would let a FreeBSD to use simple fetch(1)/curl script "freebsd-io" and maybe integrate stuff nicely. So at the beginning user would do:

        % freebsd-io init
        Enter username: wkoszek
        Enter password/key:                (whatever is necessary for REST
                                                API to do authentication)

Let's say this creates:

        % ~/.freebsd-io.cfg

Then start stuff like this, e.g.:

        % freebsd-io idea
        Enter password for wkoszek:
        Enter GSoC idea title: ................
        ...

Thanks to that organizing further GSoCs would be less pain. Basically on a frontend of http://freebsd.io/ we could have ideas fetched via jQuery from this REST API.

You could do FreeBSD-enabled pastebin with it:

        % vmstat -m | freebsd-io pastebin
        Created text bucket: 61ada4
        freebsd-io pastebin cat http://freebsd.io/pastebin/61ada4

This would let people paste the outcome on IRC. And the 2nd user could be doing 2 clicks to copy and would be running it like this:

        % freebsd-io pastebin cat http://freebsd.io/pastebin/61ada4

http://freebsd.io/ isn't in freebsd.org cluster, so we could do whatever you think could help FreeBSD. If you think putting some Amazon adds there and donating to FreeBSD could be done, we could do it.


Port NetBSD's UDF implementation

Mentor

avg@

Co-mentor

netchild@

Skills

C(advanced), Kernel(advanced)

Mid-term deliverable

Basic read-only support for new UDF

Final deliverable

Working prototype of write support. Basic write should work more or less OK.

Description

FreeBSD has an implementation of the UDF filesystem but it is quite aged and doesn't support many features from newer UDF revisions (>=2.01), it's also readonly. NetBSD implementation by Reinoud Zandijk supports most of UDF features and has write support too. Initial port could be readonly so that at least newer pre-authored media (e.g. BD) is accessible. Porting write support is a bit trickier.

Note that read-only UDF port already seems to exist, see https://github.com/williamdevries/UDF/tree/master/udf2.

Student should have basic understanding of VFS, buffer cache and filesystem implementation.

Technical Contact:


CPU online/offline project

Mentor

jhb@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The project would need to extend the current CPU states of absent and present to include absent, offline, and online. A set of event handlers (probably using EVENTHANDLER(9)) will need to be created to allow subsystems to be notified of CPU state changes. At a minimum, the functionality of the current 'hlt_cpus_mask' should be reimplemented in both the 4BSD and ULE schedulers using this mechanism. Note that the ability to disable all but one thread within a core must still be supported easily. (This is currently done on x86 via the machdep.hyperthreading_allowed sysctl.) Each subsystem that uses CPU_ABSENT() will need to be evaluated to see if it needs updating to handle online vs offline CPUs. Further improvements may include teaching UMA to free per-CPU buckets when a CPU is taken offline.

Student must have some experience with multi-threaded programming


Interactive Splash Screen

Mentor

kmoore@

Skills

C(intermediate), kernel(intermediate

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Improve upon / replace the existing static VESA splash screen support in FreeBSD, with a script-driven back-end, which allows animation in the loading graphics. This would greatly improve the bootup experience for desktop users, while providing graphical feedback to the startup of the kernel / system services. Additionally this could be used to replace the beastie.4th menu, with a VESA driven graphical loader screen.


Update Ficl in the bootloader

Mentor

Devin Teske Email: <dteske AT SPAMFREE FreeBSD DOT org>

Skills

C(intermediate), forth(basic)

Mid-term deliverable

Bring in Ficl4 in compatibility mode

Final deliverable

Update all the functionality to use the new ficl4 API

Description

Forth is a stack-based, extensible language without type-checking. It is probably best known for its "reverse Polish" arithmetic notation, familiar to users of classic Hewlett-Packard calculators. Among it's many applications it is also used in boot loading environments and since 1998 FreeBSD has supported an implementation called Ficl that works very well for that specific purpose. The new incarnation, known as Ficl 4, is faster and smaller but is not a drop-in replacement. We want this new API updated in all the code related to our boot loader.

Requirements


Port FreeBSD loader to Lua

Mentor

Wojciech A. Koszek wkoszek@

Skills

C(intermediate), kernel(intermediate)

Mid-term deliverable

Update Perforce code to -HEAD, create a port extracting Lua 5.x to src/sys/lua and make basic Lua code work

Final deliverable

Port some basic functionality to Lua

Description

FreeBSD loader gained Lua support in wkoszek_loader Perforce branch. State of this work was: Lua code can be executed from the loader. What has to be done:


Add USB target mode driver based on CTL

Mentor

trasz@

Co-mentor

hselasky@

Skills

C(advanced), Kernel(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

As it is now, the USB storage target mode driver (found at sys/dev/usb/storage/ustorage_fs.c) uses its own implementation of SCSI protocol. It would be nice to replace it by interfacing with CAM Target Layer.

Requirements


Add CD-ROM emulation to CTL

Mentor

trasz@

Skills

C(advanced), kernel(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

CAM Target Layer is a framework to implement virtual SCSI drivers, which can be then "served" to other machines using e.g. Fibre Channel or iSCSI. As it is now, CTL only provides disk emulation. It would be useful to make it possible to also support CD drive emulation, as described by SCSI Multi-Media command set (MMC-6).

Requirements:


bhyve and x86/iommu integration

Mentor

neel@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

bhyve currently supports PCI passthrough devices with its homegrown implementation of the Intel IOMMU (VT-d) driver. FreeBSD now supports a fully featured x86/iommu driver for VT-d and bhyve should start using that instead. Additionally, using FreeBSD's x86/iommu driver means that bhyve virtual machines can use the IOMMU alongside host drivers.

This project would consist adding support to the x86/iommu driver to support virtual machines i.e., support multiple device contexts within a single domain.

http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014368.html

Requirements:


Instruction caching for bhyve

Mentor

neel@

Skills

C(advanced), kernel(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

bhyve currently does instruction emulation for accesses to the virtual local APIC, IOAPIC, HPET, MSI-X table BARs etc.

The instruction emulation is expensive and can be broken down into the following steps:

1) Fetch the instruction: convert the guest %rip into a guest physical address and copy the instruction bytes into the decode buffer.

2) Decode the instruction via vmm_decode_instruction() into a 'struct vie'.

3) Emulate the instruction.

Steps (1) and (2) can be eliminated if there is already a mapping from the %rip to the decoded instruction. This in turn requires putting some checks in place to ensure that the instruction pointed to by %rip does not change unbeknownst to the hypervisor.

More details available here: http://people.freebsd.org/~neel/bhyve/instruction_caching.txt

Requirements:


Intel e1000 device model in userspace for bhyve

Mentor

neel@

Co-mentor

grehan@, emaste@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

bhyve has a virtio net PCI device emulation. However, a number of guest operating systems do not have virtio device drivers and aren't able to use this emulation. One of the best supported devices in operating systems is the Intel e1000 PCI device. An implementation of a device model for this would allow a larger number of unmodified guest operating systems to run under bhyve.

The project requires implementing the registers of the e1000 device using the existing PCI emulation infrastructure in bhyve, and dealing with transmit, receive, and control operations for the device.

This is expected to be a 2-3 month exercise including bhyve ramp up.

Requirements


bhyve in-kernel timer emulations

Mentor

grehan@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The 8254 PIT and ACPI "pmtimer" implementations in bhyve are currently in user-space. The code path from the kernel to user-space for emulated register read/write access is lengthy and has a large variance due to possible scheduling delays when passing across the user-kernel boundary. It is currently not sufficient for some operating systems that use these timers to calibrate other timers (for example, Illumos uses the 8254 to calibrate the APIC timer).

There are other general issues with timers that need to be addressed, such as the save/restore of device state when suspending/resuming/migrating a virtual machine.

This project would move the timer implementations from user-space into the kernel, in a similar manner to how the in-kernel HPET timer works. Also, the project should investigate a mechanism to allow the in-kernel timer state to be saved and restored.

Requirements:


USB device model in userspace for bhyve

Mentor

neel@

Co-mentor

grehan@, emaste@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

bhyve currently has no USB emulation. Having this would allow keyboard and mouse input for virtual machines, and also allow access to other USB devices via libusb.

The project requires implementing the registers of UHCI/OHCI/EHCI/XHCI devices using the existing PCI emulation infrastructure in bhyve, and dealing with transmit, receive, and control messaging, and also interrupts from the device.

This is expected to be a 2-3 month exercise including bhyve ramp up.

Requirements


Implement new Xen netfront/netback features

Mentor

royger@

Co-mentor

wei.liu2@citrix.com

Skills

C(advanced), kernel(medium), networking(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

This project would bring the new Xen PV nic features implemented in Linux to FreeBSD. The project includes:

Since the performance of netfront/netback is critical, the student will have to validate (by running benchmarks) that each change doesn't introduce a performance regression. Since netfront/netback implementations in Linux are under a dual GPL/BSD license there's no problem in importing code directly from Linux (when it fits).

Requirements


USB Front-End Driver

Mentor

mail@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

This project would bring para-virtualized USB support to FreeBSD XEN guests. Some information about the interface provided by XEN can be found on the XEN wiki here:

Several examples of para-virtualized drivers exist in FreeBSD and can be used to quickly create a shell driver for USB support. The tricky part will be converting the XEN USB device model (which is probably designed to Linux's requirements) into something compatible with the FreeBSD USB stack.

Requirements


SCSI Front-End Driver

Mentor

mail@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

This project would bring para-virtualized SCSI support to FreeBSD XEN guests. Some information about the interface provided by XEN can be found on the XEN wiki here:

Several examples of para-virtualized drivers exist in FreeBSD and can be used to quickly create a shell driver for SCSI support. The tricky part will be converting the XEN SCSI device model (which is probably designed to Linux's requirements) into something compatible with the FreeBSD CAM SCSI stack.

Requirements


VirtualBox shared folder support for FreeBSD guests

Mentor

lwhsu@

Co-mentor

decke@, vbox@

Skills

C (intermediate), includes C++

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Oracle VirtualBox does unofficially support FreeBSD as host and guest operating system. VirtualBox shared folder support allows to access folders of your host from within the guest system. This is similar how you would use network shares in Windows networks except that shared folders do not need require networking, only the VirtualBox Guest Additions.

This task was part of GSoC 2013 where the main focus was on porting the code to FreeBSD. The result was almost working read only support but more bugs need to be fixed and read write support needs to be added and tested.

Requirements


Ethernet Ring Protection Switching

Mentor

bms@

Skills

C(advanced), kernel(advanced, intermediate, beginner), networking(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

ERPS networks can achieve sub-50ms failover. Imagine a large fibre-optic backbone such as a Metropolitan Area Network (MAN). Where 99.9999% reliability is a requirement, ERPS is able to deliver this without compromising the future scalability and growth of such a network. Streaming a large event such as the Olympic Games may have such requirements.

If FreeBSD can be plugged directly into an ERPS network, then pfSense and FreeNAS appliances can deliver services without the need to sit behind routers. Picture a redundant Storage Area Network (SAN), serving an entire state or a county, without requiring expensive hardware load balancers. ERPS will make this and other things possible.

Requirements


Multiqueue BPF support and other BPF features

Mentor

rwatson@

Skills

C(advanced), kernel(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Note: please also look at netmap(4) http://info.iet.unipi.it/~luigi/netmap/ which is very related to the performance enhancement part of this work

The Berkeley Packet Filter (BPF) allows packet capture filters to be compiled into a bytecode that is either interpreted by a kernel virtual machine, or compiled into native machine code via a JIT and executed in in-kernel. Historically, the origin of packets has been the network interface, with each (synthetic) BPF device attached to exactly one NIC as requested by the application (for example, tcpdump). However, network interfaces have become significantly more complicated, and BPF has had to grow to support new features, such as Data Link Types (DLTs), in which BPF devices can tap network processing at different layers. This task would involve teaching BPF about a further dimension in network interface complexity: multiple input and output queues.

Modern 10gbps, and even 1gbps, network cards support multiple queues for various reasons: at first quality of service (QoS) differentiation in processing, but now especially to improve parallelism in network processing by distributing work to many CPUs on input. This same technica can also accelerate packet capture, but BPF currently doesn't know this. In this project, BPF would be enhanced to be aware of individual input and output queues on a NIC, which means providing network stack abstractions for these concepts, visible today only within device drivers. Userspace threads might then use enhanced ioctl(2)s to query the set of available queues and attach to one or more. Applications seeking maximum parallelism could open (n) devices, attaching each to a queue, and executing with appropriate CPU affinity. Ideally this would involve neither lock nor cache line contention throughout the entire stack, from device driver to userspace delivery.

Requirements


TCP/IP regression test suite

Mentor

mail@

Skills

C(intermediate), scripting (intermediate), networking (advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Design and implement a wire level regression test suite to exercise various states in the TCP/IP protocol suite. Ideally with both IPv4 and IPv6 support. This project would build on previous work in this area, please contact the project owners for more information and references to that work.

Requirements


ng_aiccu (Sixxs IPv6 tunnel broker aiccu netgraph node)

Mentor

bz@

Skills

C(advanced), networking(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The sixxs-aiccu port uses the default tun(4) interface to re-inject packets into the kernel or to send them on to a tunnel server. The netgraph subsystem in FreeBSD however would allow us to keep all the data in the kernel avoiding costly copyin/outs while still doing control message handling in user space. Implement a netgraph node that can be connected to a netgraph kernel socket node and a netgraph interface node and understands enough of the AYIYA protocol to pass packets back and forth. Use a control connection to user space to handle all other signalling. Adjust the sixxs-aiccu implementation and add the netgraph implementation as an option for the FreeBSD port.

Requirements


A New Audit Parsing API

Mentor

rwatson@

Co-mentor

trustedbsd-audit@TrustedBSD.org

Skills

C(intermediate), security (advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The current OpenBSM audit parsing API has a number of limitations, not least that it can't handle little endian BSM records that may come from Solaris x86 systems, in terms of ABI robustness in the presence of new record types, ability to process trails generated non-locally in terms of supporting uid/gid->name translation, and in terms of incrementally processing a byte stream from, for example, socket sources without using the C FILE API.

This task would consider existing audit parsing APIs in the industry, including POSIX.1e, relevant Open Group specs, and in-use APIs on other systems such as Solaris, Linux, Windows NT, and others, in order to first identify an existing candidate API or design a new candidate API, then implement the API and adapt existing audit applications to use it. The task would also document the API using man pages, create an audit parsing tutorial document, create a test suites, and require interaction with the OpenBSM and FreeBSD communities to identify audit parsing requirements.

If successful, the results of this work would be integrated into OpenBSM, the open source BSD-licensed audit framework shipped with FreeBSD and Mac OS X.

Requirements


Linux to BSM Conversion Tool

Mentor

rwatson@

Co-mentor

trustedbsd-audit@TrustedBSD.org

Skills

C(intermediate), security (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The BSM (Basic Security Framework) audit trail format is the de facto industry standard for portable operating system audit trails, being supported on Solaris, FreeBSD, and Mac OS X. However, many other audit trail formats exist that are less portable, including audit trail formats local to Linux.

This task would create BSD-licensed conversion tools to import audit trails from other systems and convert them to BSM format so that they can be inspected and managed using the OpenBSM tool set. This would require the creation of BSD-licensed parsers for audit trail formats of interest, designing and documenting a semantic mapping to the BSM trail format, and writing conversion utilities using the new parsers, semantic mapping, and BSM generation routines in OpenBSM. A key part of this work would be to rigorously understand and document the mapping and its limitations. A test suite is also required.

If successful, the results of this work would be integrated into OpenBSM, the open source BSD-licensed audit framework shipped with FreeBSD and Mac OS X.

Requirements


Capsicum application adaptation and core libraries

Mentor

rwatson@

Co-mentor

benl@

Skills

C(advanced), security(intermediate

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Capsicum is a new sandboxing mechanism designed for FreeBSD based on the capability security model. Initial Capsicum features are being merged to the FreeBSD 9.x kernel, but a lot of work remains to be done. Of particular interest is identifying applications that might use Capsicum, and factoring out support libraries providing features needed by many applications. For example, it should be easy to use DNS in a Capsicum sandbox but currently isn't; we might adapt the lightweight resolver daemon to serve Capsicum sandboxes, modify the resolver library to use it when in Capsicum, and modify libcapsicum to delegate resolver access to sandboxes where appropriate. Similar work could be done to provide certain types of file access authorisation, and perhaps even derive delegation requirements from ELF annotations.

References:


Unattended encrypted kernel crash dumps

Mentor

gleb@

Co-mentor

jmg@

Skills

C(intermediate), Scripting(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Unencrypted crash dumps pose a security risk by exposing sensitive information, while dumps remain useful tool for debugging panics in production environment.

Project would consist of several parts:

Requirements


KDE front-ends to the freebsd-update(8)utility

Mentor

cperciva@

Skills

C(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The freebsd-update(8) utility is used to fetch, install, and rollback binary updates to the FreeBSD base system. A nice project would be to develop a graphical front-end for freebsd-update(8), using the QT toolkit. A GTK frontend was developed as part of GSoC 2007 and exists at berlios; the QT frontend could maybe share common functions/classes and design ideas.

Requirements


IPv6 User Land Cleanup

Mentor

mail@

Skills

C(intermediate), networking (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Many 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 further be split up. Some more of this includes:


Use CTF data for libkvm

Mentor

jmg@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

CTF provides type information such as structure member types and offsets. Instead of requiring utilities like netstat be compiled for a specific architecture it would allow the same binary to read the data from different arches, and the ability to read data from kernel dumps even when the kernel is much older than the utilities.


Libprocstat and libnetstat

Mentor

rwatson@

Co-mentor

pgj@

Skills

C(intermediate), networking (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Create, similar to libmemstat, wrapper libraries to support monitoring and management applications to avoid direct use of kvm. Three parts to the project: for each of the above, add kernel support to export data in a less ABI-sensitive way using sysctl, write a library to present the information in an extensible way to applications, and update applications to use the library instead of reaching directly into kernel memory / consuming sysctls. The goal is to allow the kernel implementation to change without breaking applications and requiring them to be recompiled, and to allow monitoring functions to be extended without breaking applications. This should also facilitate writing new classes of monitoring and profiling tools.

For progress made on this sub-project so far, see its page on the wiki.

Requirements


Improve Wine support in FreeBSD

Mentor

kris@pcbsd.com

Skills

C(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Wine is usable on FreeBSD. However, there are some issues which still need to be addressed at Wine. This would be a big improvement for our desktop users.


BSNMP enhancements

Mentor

syrinx@

Skills

C(intermediate), networking (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Bsnmp is a portable SNMP framework consisting of a daemon, modules and tools. It includes libraries that ease the development of loadable modules for configuring and monitoring various subsystems. You can find more information about Bsnmp. Some project ideas, but not limited to that list, can be found at BsnmpTODO.

Requirements


Port TrueCrypt as a geom_gate userland disk device implementation

Mentor

ivoras@

Co-mentor

jmg@

Skills

C(advanced), kernel(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

TrueCrypt is a popular cross-platform on-the-fly disk encryption software. Recently tcplay, a BSD licensed option, has been developed. It should be straightforward to port it as a geom_gate device in userland.

Requirements


Userspace pthread mutex lock contention profiling and lock order verification tool

Mentor

jeff@

Skills

C(advanced)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

This task would create an extension to the threading library that would allow application developers to measure and locate lock ordering and lock contention problems within their application. Such a tool is invaluable in debugging application deadlocks and creating high-performance multithreaded software. Existing lock ordering and profiling tools exist in the FreeBSD kernel, and could be used as the model for the userspace implementation. We would recommend beginning with profiling due to its immediate usefulness in optimizing performance, and to allow improvements in kernel scheduling to better manage user application lock contention.

Requirements


FreeBSD port of NetworkManager

Mentor

marcus@

Skills

C(intermediate), networking (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

This task is to port NetworkManager to FreeBSD. Porting NetworkManager will also require some core userland changes to FreeBSD, especially to ifconfig.

Requirements


Fix FreeBSD support in GNOME's system-tools-backends

Mentor

marcus@

Skills

C(beginner)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

This task is to fix FreeBSD support in sysutils/system-tools-backends.

Requirements


Finish support for compilation of i386 binaries on amd64

Mentor

kib@

Skills

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

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The FreeBSD binutils and gcc on amd64 are capable to build 32bit binaries. What we miss is the proper includes for i386 accessed when #include <machine/some.h> is used, for the -m32 invocation of the cc. Project would provide an installation of both amd64 and i386 includes in non-conflicting way, and changes to the gcc to select proper location for machine/ based on the compilation target architecture.

Requirements


Improve webcamd support

Mentor

hselasky@

Skills

C(intermediate), kernel(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Enhance the Webcamd Project. Update drivers to latest version available in the Linux kernel. Improve build system. Perform testing.

Requirements


Improve Collation and Multibyte Support in Libc

Mentor

David Chisnall (theraven@)

Skills

C(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

Improve the wide character and multibyte support in FreeBSD libc. A previous GSoC project KonradJankowski/Collation provided an improved strcoll(). Once this is finished, tidied, and merged, a strncoll_l() function would be relatively easy to add - this has been requested for PostgreSQL (which needs to maintain sorted-by-locale columns for various things). There are also several places where the existing wide-character functions in libc contain FIXMEs. Illumos has some recent BSD-licensed support we should look at.

Requirements


Teaching DDB to speak CTF

Mentor

rwatson@

Skills

C(intermediate), kernel(beginner)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

DDB is FreeBSD's built-in kernel debugger, providing rudimentary on-console debugging support: initial crashdump analysis, lock analysis, breakpoint management, data structure inspection, basic scripting, as well as the ability to switch to remote GDB. Over the years, DDB has become tightly integrated with a number of our kernel subsystems, learning about printing out lock information, having "pretty printers" for several important kernel data types, etc. However, DDB has suffered from a lack of automatic access to contextual debugging information: it can inspect the kernel symbol table, but to print a data structure it has to be explicitly taught about the data structure. This project idea is to teach DDB how to use the CTF data used by DTrace to keep track of kernel data types. In theory, DDB could use this same information to create automatic pretty printers for all kernel data structures, rather than requiring explicit code for each type.

Requirements


Mandatory Access Control

Mentor

rwatson@

Skills

C(intermediate), kernel(intermediate), security(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

FreeBSD 5.0 was the first FreeBSD release to ship with support for Mandatory Access Control (MAC), an access control technology allowing system administrators to implement multi-level security, integrity protection, and other "mandatory" policies. Policies may be compiled into the kernel, or loaded as loadable kernel modules. Later revisions of FreeBSD and the MAC Framework enhanced MAC support, and additional policy modules were made available, such as a port of the SELinux FLASK/TE framework available as a third party policy module. However, many of the sample MAC modules included with FreeBSD are considered experimental examples of what the technology can be used for, rather than production policies. For example, the Biba integrity policy can be deployed in production, but requires significant tuning to do so effectively.

This task involves a general review of the MAC Framework and Policy modules, with the goal of identifying improvement areas. It also involves specific cleanups, optimizations, and completeness work on specific policy modules -- most importantly, the Biba and MLS sample labeled policy modules. Work there includes improving memory overhead and efficiency; for example, moving from allocating complete labels for every labeled object to referencing common label storage where labels are identical, which occurs a great deal of the time in most systems. Other cleanups include moving towards a canonical/extensible on-disk label storage format, adding regression tests, investigating interactions with user applications, and writing documentation.

Requirements


Path-based file system MAC policy

Mentor

rwatson@

Co-mentor

trustedbsd-discuss@TrustedBSD.org

Skills

C(advanced), kernel(intermediate), security (intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

The TrustedBSD MAC Framework makes it easy to extend the FreeBSD kernel security model using pluggable modules, which has provided support for "traditional" mandatory access control, as well as allowed a number of companies to build local security policy extensions for workstation, server, and appliance products; one such example is Apple's "Seatbelt" policy for Mac OS X. However, the base system MAC policies are difficult to use, primarily because they either don't extend security meta-data (ugidfw) or they require extensive labeling (Biba, MLS). This project idea involves crafting a new OS security policy extension along the lines of ugidfw, the file system firewall, but using path names instead of existing file properties to manage protection. This requires careful thinking about what a file system path "is" in the UNIX environment, as well as regarding what sorts of policies would be useful.

Requirements


Security regression tests

Mentor

rwatson@

Skills

Scripting (intermediate), security(intermediate)

Mid-term deliverable

Explain what MVP for mid-term is

Final deliverable

Explain what MVP for final term is

Description

FreeBSD is undergoing constant and active improvement to all of its critical subsystems, from file systems to the network stack. With any change, there is a risk of introducing bugs or regressions. The goal of this task is to produce a security regression test suite, which encapsulates requirements regarding system security properties and tests that they (still) hold. Areas to test include file system access control, privilege, authentication, cryptography, process containment, and more. There are some current tests along these lines in the http://svnweb.freebsd.org/base/head/tools/regression/, but they are both incomplete and and inadequate. New tests must be created; existing tests must be completed and updated.

Requirements


kgdb support for devel/gdb port

Mentor

mail@

Skills

C(advanced), kernel(intermediate)

Mid-term deliverable

Try to have kgdb working for at least one architecture

Final deliverable

An option to build kgdb in devel/gdb

Description

gdb in the base system is quite old and by extension kgdb is lacking many features which are available in recent gdb versions. devel/gdb port provides a modern version of gdb. The project would consist of porting kgdb code from older gdb interfaces to the newer one. devel/gdb should grow an option of building kgdb binary provided that FreeBSD source tree is available.


kernel debugging support for LLDB

Mentor

emaste@freebsd.org

Skills

C++(intermediate), kernel(intermediate)

Mid-term deliverable

Basic support for opening kernel cores and /dev/mem

Final deliverable

Full support including module loading

Description

Userland debugging support for FreeBSD in LLDB is progressing nicely, but there is currently no support for kernel debugging. This project will consist of adding a libkvm interface to LLDB to open kernel cores, as well as live debugging against /dev/mem, as well as parsing module metadata to automatically load kernel modules in the debugger.


High-speed firewall: convert IPFW/PF/Your-Firewall rules to C module

Mentor

Wojciech A. Koszek wkoszek@

Skills

C(advanced), kernel(advanced), network(advanced)

Mid-term deliverable

1-3 simple ipfw/pf rules which can be streamed via converted, which will make dir+.c/Makefile, which compiles, loads to the kernel and does correct filtering

Final deliverable

Same as mid-term, but with more sophisticated rules

I'd say there are two ways to approach this task:

ANSI C is the universal language for all systems, including FreeBSD/NetBSD and Linux. It works on any FreeBSD release. It also lets everyone to take advantage of C compiler optimization. Using it as a intermediate representation would let us to convert:

if (packet.from == "0.0.0.0/0" && packet.to == host_me && packet.dst_port == 80) {
    packet.to = "127.0.0.7";
    packet.dst_port = 8080;
}

and get this converted to a KLD, which can be loaded to the kernel.

The way I think I'd go about it is:

Pluggable repository support for pkg(8)

Mentor

bapt@

Co-mentor

mail@

Skills

C(intermediate), Packaging(intermediate)

Mid-term deliverable

A ports repository support

Final deliverable

An external language repository support

Description

Improve pkg(8) repository handling to introduce a pluggable repository to allow pkg(8) to use different kind of sources like (for example):

Support goes from being able to update the database, translate version scheme into FreeBSD version scheme, install packages from those sources and mix them with regular packages. The Summer of code could be devided in 2 parts, the first one will focus on the FreeBSD ports tree. The second one will do the same on a "language" repository: opam, cpan, pypy, or gems.

Memory compression and deduplication

Mentor

theraven@

Co-mentor

Skills

C(advanced), kernel(advanced)

Mid-term deliverable

A swap pager capable of paging compressed data to wired kernel memory

Final deliverable

Either the ability to store compressed pages on disk (compressed swap) or live deduplication of inactive memory

Description

Memory-constrained devices also often lack swap space (or, when they have it, it is flash do they don't want to use it too much). There are two well-known approaches to addressing this:

Compressed memory is somewhat harder than normal swapping because the size of the compressed pages is not fixed. This means that more aggressive defragmentation is needed. The normal pager interfaces in the VM subsystem can probably be used, with the pager reserving some physical memory for use storing compressed pages. There are several possible directions for this:

Deduplication will involve identifying identical pages and combining them. This is a harder project, as the synchronisation required is complex. Students attempting this part of the project will become very familiar with WITNESS. A successful student could provide a good implementation of compression, without investigating deduplication.

Implement KDBUS

Mentor

theraven@

Co-mentor

Skills

C(intermediate), kernel(intermediate), security(intermediate)

Mid-term deliverable

Basic support for one-copy and broadcast messages

Final deliverable

Full kdbus implementation, including Linux ABI support

Description

KDBUS is a new kernel IPC primitive from Linux, which is increasingly required for desktop and mobile applications. It also has some interesting potential for integration with capsicum.

The basic model for KDBUS is:

KDBUS on Linux is often combined with memfd, however FreeBSD provides anonymous shared memory via the POSIX shared memory interfaces so this is not required (except, perhaps, in purely userspace compatibility shims).

Port old-style regression tests to ATF

Mentor

jmmv@

Skills

C (intermediate), shell (intermediate/high), make (intermediate)

Mid-term deliverable

sbin, usr.bin and usr.sbin tests ported over

Final deliverable

As many tests from src/tools/{regression,test} ported over, hopefully all

Description

The FreeBSD source tree includes a bunch of legacy tests under src/tools/regresion/ and src/tools/test/. Because there is no framework to easily run these tests and there are no continuous testing machines running them, these tests are never run and a good bunch of them are broken.

The goal of this project is to revive all these tests by plugging them into the shiny-new test suite bundled with FreeBSD. Ideally, by the end of the summer all legacy tests should have moved over.

The approach to move a test is the following:

1. Make the test pass if at all possible in its current form; if not possible, see below. Commit the fixes to the tree.

1. Move the test code into its "real" location under a tests/ subdirectory.

1. Plug the moved tests into the test suite, possibly by using the TAP support in Kyua (see tap.test.mk). Commit this to the tree.

1. Convert the test code to ATF and commit to the tree. This involves two things:

  1. Ensuring that every test case is clearly separated in its own test case definition as provided by ATF.
  2. Getting rid of auxiliary data files. Most tests should be self-contained in a single program and not require external files to run. Makes for a leaner test suite in /usr/tests/.

Garrett Cooper also maintains a good collection of already-converted tests in his GitHub tree. You can use those as sources as well.

Note that this work must happen iteratively and results must be committed to the main tree as they happen. It is NOT acceptable to convert the tests in a separate repository.

Flexible dependency support for pkg(8)

Mentor

bapt@

Co-mentor

vsevolod@

Skills

C(intermediate), Packaging(intermediate)

Mid-term deliverable

A ports repository support

Final deliverable

An external language repository support

Description

Implement flexible dependency support for pkg(8) to allow ports depending on the following patterns: - Flexible version: perl>5.12<=5.18 - Depend on provides/requires (keywords): http, www etc

Submitted over WWW form, need review


Task name*: Implement direct boot from ZFS pool on a GELI encrypted device

Submitter (you):

Mentor*: Pawel Jakub Dawidek

ANSI C*: Advanced

Kernel*: Advanced

Networking*: Intermediate

Security*: Intermediate

Computer architecture*: Intermediate

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Implement direct boot from ZFS pool on a GELI encrypted device.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Implement direct boot from ZFS pool on a GELI encrypted device.

Description (detailed)*: Implement direct boot from ZFS pool on a GELI encrypted device.


Task name*: Unified ping and ping6

Submitter (you): Mark Martinec <Mark.Martinec@ijs.si>

Mentor*: perhaps Bjoern A. Zeeb would be willing?

Co-mentor:

ANSI C*: Intermediate

Kernel*: Not required

Networking*: Advanced

Security*: Beginner

Computer architecture*: Beginner

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: A working unified ping program with basic functionality in both protocol families, not yet supporting all features of existing ping and ping6. A list of identified tasks still to be worked on.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: A working and documented unified ping program supporting all features of existing ping and ping6 programs. An automated test procedure for checking most of the features.

Description (detailed)*: For historical reasons the IPv6 equivalent of a ping command was developed by a KAME project as a separate utility ping6. Even though the underlying protocols are different, both programs were derived from the same source code and are functionally very similar from a user's perspective. Several commercial platforms (e.g. routers, MS Windows) already offer a single command to cover both protocols which proved natural for usage, and facilitate its usage especially in scripts and automated network tests.

Study source code of existing programs ping.c and ping6.c in FreeBSD, compare it to current code in NetBSD and OpenBSD. Merge (or rewrite) ping.c and ping6.c into a single program (in C) which chooses the protocol based on provided IP address or host name, possibly overridden by new options -4 or -6. Try to preserve backward compatibility of command line options and their functionality as much as possible. Cleaning code of historical artifacts and adhering to current RFC documents is desired too. If the program is called (in argv[0]) as ping6 it should behave as an existing ping6. Document it in a man page. Create an automated test procedure to check most if not all of the program features.


Task name*: Unified traceroute and traceroute6

Submitter (you): Mark Martinec <Mark.Martinec@ijs.si>

Mentor*: perhaps Bjoern A. Zeeb would be willing?

Co-mentor:

ANSI C*: Intermediate

Kernel*: Not required

Networking*: Advanced

Security*: Beginner

Computer architecture*: Beginner

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: A working unified traceroute program with basic functionality in both protocol families, not yet supporting all features of existing traceroute and traceroute6. A list of tasks still to be worked on.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: A working and documented unified traceroute program supporting all features of existing traceroute and traceroute6 programs. An automated test procedure for checking most of the features.

Description (detailed)*: For historical reasons the IPv6 equivalent of a traceroute command was developed by a KAME project as a separate utility traceroute6. Both existing programs were derived from the same source code and are functionally very similar from a user's perspective. Several commercial platforms (e.g. routers, MS Windows) already offer a single command to cover both protocols which proved natural for usage, and facilitate its usage especially in scripts and automated network tests.

Study source code of existing programs traceroute.c and traceroute6.c in FreeBSD, compare it to current code in NetBSD and OpenBSD. Merge (or rewrite) traceroute.c and traceroute6.c into a single program (in C) which chooses the protocol based on provided IP address or host name, possibly overridden by new options -4 or -6. Try to preserve backward compatibility of command line options and their functionality as much as possible. Cleaning code of historical artifacts and adhering to current RFC documents is desired too. If the program is called (in argv[0]) as traceroute6 it should behave as an existing traceroute6. Document it in a man page. Create an automated test procedure to check most if not all of the program features.


Task name*: FreeBSD preseed installation (PXE)

Submitter (you): Loïc Blot <loic.blot@unix-experience.fr>

Mentor*: Ken Smith

Co-mentor: Nathan Whitehorn

ANSI C*: Beginner

Kernel*: Beginner

Networking*: Intermediate

Security*: Intermediate

Computer architecture*: Beginner

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: FreeBSD must be installable and bootable by PXE without a NFS mount

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: FreeBSD must be installable by PXE and the installer must get a preseed file to configure all the installer without a human intervention

Description (detailed)*: The idea is to create a specific FreeBSD distro to boot by PXE and install all the distribution by using a preseed file. The sets must be downloaded from a official/custom repository. No network device mount must be done. Installation must be fully automated at the end. pkg installation will be a plus.


Task name*: Port kdbus, udev, and systemd

Submitter (you):

Mentor*:

Co-mentor:

ANSI C*: Advanced

Kernel*: Intermediate

Networking*: Beginner

Security*: Not required

Computer architecture*: Beginner

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Sort of working ports

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Fully working ports

Description (detailed)*: It's would be good to have these, since they're popular in Linux, thus installing any ports which are supported on Linux would require less porting effort. For example, if udev existed (or devd handle'd udev's format), we could use Linux+USB stuff easier.


Task name*: Implement CGroups or similar

Submitter (you): Shanice Skipper

Mentor*:

Co-mentor:

ANSI C*: Intermediate

Kernel*: Intermediate

Networking*: Not required

Security*: Not required

Computer architecture*: Not required

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Processes can belong to a CGroup.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Tags don't disappear mysteriously. libcgroup or similar implemented.

Description (detailed)*: CGroups are a feature of the Linux kernel which is also available in GNU Mach and a similar system exists in Solaris/illumos called 'Process Contracts'. It is effectively a tag applied to a process that cannot be removed, even by a child who reparents to init. There are some similarities to jails, but CGroups is more modular. For an initial implementation, just isolating a CGroup from its parent is fine.


Task name*: implement Intel Supervisor mode access prevention and bootime

kernel patching framework

Submitter (you): Oliver Pinter + oliver.pntr (at) gmail.com

Mentor*: kib

Co-mentor: neel

ANSI C*: Intermediate

Kernel*: Advanced

Networking*: Not required

Security*: Intermediate

Computer architecture*: Intermediate

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Design and implement basic SMAP support, without boot-time / run-time kernel patching. PASS: The kernel should panic, when the kernel deref not allowed userspace memory.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Design and implement SMAP support with boot-time / run-time kernel and module patching.

PASS: The kernel should panic, when the kernel deref not allowed userspace memory and it is possible to load modules contains patchable sections.

Description (detailed)*: Intel SMAP is an hardware extension to support advanced kernel self protection. The SMAP technology will appear in Intel Broadwell architecture in 2014.


Task name*: Improve debugging capabilities of RC startup scripts

Submitter (you):

Mentor*: FreeBSD

Co-mentor:

ANSI C*: Intermediate

Kernel*: Intermediate

Networking*: Intermediate

Security*: Intermediate

Computer architecture*: Intermediate

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: To identify how the RC startup scripts can be cleaned up to make them better suited to the changes that are occurring with FreeBSD.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: RC startup that keeps the current flexibility but presents it in a more readable and readily identifiable form to aid in debugging problems.

Description (detailed)*: One of FreeBSD's strengths and weaknesses is its robust and flexible RC startup scripts.

Often times though, trying to find what is a problem at startup requires you to dig through the myriad of stuff spewed to the console and log files.

This task would be to keep the flexibility and robustness of the system, but cleanup and organize how it displays the information presented -- making it better suited to debugging and fixing problems.


Task name*: Fast Reroute with quagga and FreeBSD

Submitter (you): Kurt Jaeger fbsd-gsoc2014@opsec.eu

Mentor*: Kurt Jaeger

Co-mentor:

ANSI C*: Intermediate

Kernel*: Intermediate

Networking*: Advanced

Security*: Beginner

Computer architecture*: Beginner

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: 1) Measure re-routing times for quagga, bgpd and freebsd in case of link loss.

2) Bring http://sourceforge.net/projects/bfdd up to date with FreeBSD and Quagga.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Analyse the data structures to handle multiple routing/forwarding tables in the FreeBSD kernel, possibly computed by multiple cores.

Find a way to switch between those routing/forwarding tables depending on some trigger from quagga/bgp/bfdd.

Description (detailed)*: FreeBSD based bgpd routers need to re-route quick in case of outages. Quick means < 50ms so that voice calls do not notice the outage.

For this to work, three things have to work:

1) FreeBSD has to detect link outages across large Layer-2 domains (lots of switches) very fast. BFD (RFC5880 and RFC5881) provides a way to achieve this.

2) quagga/bgpd has to precompute multiple routing tables (or FIBs, forwarding information bases) so that it can switch 'quickly' to one that handles a lost link. Every incoming bgp update is applied to the current and some alternative routing tables.

3) In case of outage, bgpd triggers a switch to the correct alternative routing/forwarding table.


Task name*: Dragonfly Mail Agent Cleanup

Submitter (you):

Mentor*: FREEBSD MENTOR

Co-mentor:

ANSI C*: Intermediate

Kernel*: Intermediate

Networking*: Intermediate

Security*: Intermediate

Computer architecture*: Intermediate

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Conduct a review of DMA to see what needs to be done to make it a 100% viable base system replacement for sendmail.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Update DMA to be a 100% replacement for sendmail as part of the base system.

Description (detailed)*: There is currently a discussion in the mailing lists about replacing the huge Sendmail program that is part of the base system with DMA, so that the attack footprint of a newly installed system is smaller, capiscumized, and able to support sending of e-mail only.

DMA would need to be fixed/modified to be a drop-in replacement for sendmail submit as part of the base system with the ability to be completely replaced with sendmail (or even postfix or another mailer) from the ports with little to no changes needed.


Task name*: FreeBSD ZWave implementation

Submitter (you):

Mentor*: FREEBSD MENTOR

Co-mentor:

ANSI C*: Advanced

Kernel*: Advanced

Networking*: Advanced

Security*: Advanced

Computer architecture*: Advanced

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Analyze how to make various USB ZWave dongles work with FreeBSD

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Create the framework and enable the use of two mainstream ZWave USB dongles on FreeBSD

Description (detailed)*: Home automation (HA) is a fast growing market, with a lot of competition. Unfortunately for the *BSDs, this is primarily a Windows or custom Linux controlled market.

Since FreeBSD is a very robust OS, it having it as a viable platform for HA should be a no-brainer.

This GSOC idea would require the person completing to project to do extensive research on the ZWave protocol, likely needing to get access to the ZWave spec by signing the NDA, and then getting at least two popular/mainstream ZWave USB dongles fully working with FreeBSD (not partial implementations that require voodoo to get working sometimes).

Once this groundwork has been done, this will open up FreeBSD as a viable platform in the HA world.

gavin notes: Going by http://wiki.domogik.org/plugin_ozwave the 'Aeon Z-Stick 2' should already be supported by uslcom, but other devices may need a new driver (Linux cdc_acm).


Task name*: Support for Google Chromebook

Submitter (you):

Mentor*: FREEBSD MENTOR

Co-mentor:

ANSI C*: Advanced

Kernel*: Advanced

Networking*: Advanced

Security*: Advanced

Computer architecture*: Advanced

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Research current status/problems with FreeBSD running on Google's Choromebooks

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Fix FreeBSD to run on Google Chromebooks, to include making installation easy to do.

Description (detailed)*: FreeBSD currently has some problems when being booted/run on a Google Chromebook.

This GSOC project aims to make FreeBSD compatible out of the box with the Google Chromebook, to include making it easy to install.


Task name*: FreeBSD Kernel FULL_PREEMPTION

Submitter (you):

Mentor*: FREEBSD MENTOR

Co-mentor:

ANSI C*: Advanced

Kernel*: Advanced

Networking*: Advanced

Security*: Advanced

Computer architecture*: Advanced

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Research having FULL PREEMPTION as a viable non-debug option in the kernel, including what it would do/cause if turned on.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Cleanup code to enable FULL PREEMPTION use in a non-debug environment.

Description (detailed)*: It has been asked, and stated that the FULL_PREEMPTION option was meant to be used in a debugging environment to check for deadlocks and other stuff.

This proposal would move this from a debug only option to something that could be used ina production environment.

It would require identifying and documenting the quirks/problems with enabling this, fixing the major issues and documenting how to use/best practices for using this option in a production environment.


Task name*: FreeBSD NTPD replacement

Submitter (you):

Mentor*: FREEBSD MENTOR

Co-mentor:

ANSI C*: Advanced

Kernel*: Advanced

Networking*: Advanced

Security*: Advanced

Computer architecture*: Advanced

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Research the viability of replacing the full NTPD daemon in base with something lightweight but maintain compatibility.

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Implement an NTPD replacement in base that is mostly compatible with the main functions of NTPD.

Description (detailed)*: NTPD is another program in base that may be overkill, but completely removing it may cause a lot of things to break.

This proposal would be to research, identify and document how to replace NTPD in base while maintaining compatibility with NTPD for it's most used basic features.

It would also be to document how to install the full NTPD program from ports, as well as submitting patches to the installer to choose having the full NTPD installed.

Switching from the minimalist NTPD replacement to the full NTPD should be 100% compatible with minimal to no changes needed to the system configuration as a drop in replacement.


Task name*: FreeBSD Installation on air-gapped systems

Submitter (you):

Mentor*: FREEBSD MENTOR

Co-mentor:

ANSI C*: Advanced

Kernel*: Advanced

Networking*: Advanced

Security*: Advanced

Computer architecture*: Advanced

Mid-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Research the best methods to creating a FreeBSD installation method for air-gapped systems (with ports, compiled on system if necessary)

Final-term deliverable, 2-3 sentences. Absolute minimum to give "PASS" score to a student*: Implement a fully functional installation method for allowing FreeBSD to be installed on an airgapped system with ports.

Description (detailed)*: Installation of a modern OS like FreeBSD on an air-gapped system can be a frustrating experience, especially when one needs/wants to install software with all the related dependencies from the ports system.

This project would be to research, document and create a way to make installing FreeBSD with ports on air-gapped systems and keeping it updated less of a painful process.

Ideally, installation on/in an air-gapped environment would be a native/organic feature of the installer -- with the installer taking care of ensuring any dependencies for ports were available in creating the installation medium/actual installation on the air-gapped system without needing to compromise system integrity or making it an exercise in pain.

SummerOfCode2014Ideas (last edited 2015-01-19 20:22:20 by GavinAtkinson)