• SummerOfCode2014Ideas

FreeBSD Google Summer of Code 2014

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

Application

• FreeBSD page on Google Melange: http://www.google-melange.com/gsoc/org2/google/gsoc2014/freebsd

• Apply here: https://www.google-melange.com/gsoc/homepage/google/gsoc2014

• Critical dates: https://www.google-melange.com/gsoc/events/google/gsoc2014

For mentors

• For best student experience, tasks SHOULD have 2 mentors. Please remember that some students may require significant time for coordination/reviews.
• Students may come with different backgrounds
• A blank template is available at the top of the ideas list when you edit the page

For students

• You should propose the design of your idea first, and only start coding once your project is accepted. Producing a decent design will save you lots of effort.
• Most mentors are working professionals. Please use their time effectively, with up-front study of issues and problems, and try to provide as much data as possible.

• We have a page at SummerOfCodeDevEnvironments where we detail some possible ideas for how to set up your developer environment.

• We also have several pieces of advice on applying at SummerOfCodeStudentChecklist

• The list of projects here should be regarded as inspiration, not as the exclusive list of all projects that will be considered. We are happy to try to find mentors for projects that will benefit the FreeBSD project. If you're unsure if your idea fits this description, try asking in #freebsd-soc or #bsddev on EFNet.
• Lua is not currently in the FreeBSD base system, so projects involving Lua have less chance of being imported. This does not mean that they may not be valuable learning experiences, but note that we are more likely to award our limited number of slots to students doing work that may directly and immediately benefit the project.

Skill levels

• C: For C-related ideas, general fluency with basic programming in low-level language is necessary. Judge by yourself. You know yourself the best. If you know you barely understand written source-code and you pick a hardcore kernel project, you'll have a problem. You can either treat it as a challenge, commit to doing it and learn FreeBSD by doing, or just pick something simpler. Generally, it is easier to program/debug userland software than it is when working on the kernel. Kernel programming.debugging is harder, and can involve skills ranging from understanding internals of operating systems construction to computer architecture. We encourage picking projects which you feel you can realistically do within the 12-week timeline

• Kernel: The FreeBSD kernel is written in C, so at least a basic proficiency in C is required. Various levels of other skills may be necessary, but you can assume that knowing how to do "Hello world" in the kernel should be a good starting point for picking kernel projects.

• Network: Understanding of TCP/IP will be required for these projects. It'd be good if you understood socket API for any programming language, and know stuff like "sockets".

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

• Scripting: For scripting, we won't be enforcing which language you choose. However there are certain factors for this choice: if you're willing to work with /bin/sh, our installer is written in it and there's a high likelyhood that whatever you produce will get commited to the base system. If you pick something like Lua, you're on your way to R&D and marketing of your solution, since it's something possible to get into the tree, with some level of commitment and convincing. For other things which are too big for the base system and not present there yet (e.g.: Perl), you'll can still contribute to tools. Tools are equally important as every part of the OS. If you create a tool for debugging, analyzing and visualizing complex data, it might help dozens of FreeBSD hackers around the world to be 10x more productive

List of ideas

Ideas list

Machine readable output from userland utilities

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:

• sysctl
• ifconfig
• netstat
• iostat
• vmstat

Requirements:

• Understanding of basic frameworks, libraries and APIs.
• Understanding of one or more machine readable formats (XML/JSON/YAML).
• Ability to understand one of the basic C libraries for emitting machine readable data. (libxml, libjson)

---

Port FreeBSD on a smartphone (any maker and model)

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

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)

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)

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:

• watching FreeBSD commits
• scheduling builds each time new commit is seen
• building complete images of FreeBSD for x86, ARM, MIPS, SPARC (this is a very large topic and you'd have to pick 1 thing)
• running an emulator with certain builds and taking a screenshot at the end.
• observing whether regressions are seen

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

Requirements

• Strong scripting skills (Perl, Python, Lua)
• Knowledge of the FreeBSD build system

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

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

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)

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:

• import Lua to src/sys/lua
• make it compile as a binary program
• go to src/usr.sbin/config
• understand it (this point is more tricky than it sounds)
• take GENERIC kernel and strip it out as much as possible. Try to work with minimal functionality for now.
• test it with config(8) and make this kernel compile (old config. system test)
• sketch a proposal on minimal Lua syntax (API) which would let you to bring all necessary information from src/sys/conf/... to Lua
• implement this API in Lua
• try to map this minimal kernel config (covered before) to Lua
• convert src/sys/conf/ to src/sys/conf/freebsd.lua
• make it generate correct makefiles etc...
• make it work

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

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:

• - look at FreeBSD/ARM code for OS kernel and figure out if SMP kernel can be used, with startup of 2nd CPU blocked
  • - maybe you'd need to just use UP-kernel and be done here.
  - study ARM docs and see what stuff is being shared among CPU cores, and what doesn't - ask yourself which of the shared resources are used in the OS and what can cause collisions - write bare-metal application for a platform you'd pick and would test it - start FreeBSD on 1st core, load your app in the memory and try to kick 2nd CPU to execute it
  • - see what happens - make it work

  - you'd collect pieces together and try to provide a program under FreeBSD, which could be run like "start_my_2nd_os <file.elf>", which would take ELF

---

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

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:

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:

• users create a social community, which helps with system development
• entrance barrier from 0 to helping with system development is decreased to minimum.
• users can use already-existing accounts to use FreeBSD ID (basically can login with their LinkedIn/FB+ profiles)
• bug database is tied to the community portal.

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

• mostly in node.js ideas, since lots of modules are already there and just need integration
• creating REST-based API (platform), so that other services can be used on top of this API.

• pure website with 0 time spend on graphics: we'd use TwitterBootstrap for CSS/HTML.

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:

• help us run further GSoCs by letting people submit ideas from their
  • accounts.

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

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:

• M. McKusick, G. Neville-Neil, The Design and Implementation of the FreeBSD Operating System (ISBN 0-201-70245-2)

• UDF 2.60 OSTA Specification

• Volume and File Structure for Write-Once and Rewritable Media using Non-Sequential Recording for Information Interchange

---

CPU online/offline project

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

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

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

• Special attention must be taken to preserve the low-memory footprint and to preserve the local enhancements we provide.
• You are also expected to identify possible optimizations that can be done with the new API.

---

Port FreeBSD loader 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:

• look at Forth code in the loader and prepare technical specs -- list of functionality that is actually present there
• make yourself comfortable development environment, so that you can test Lua code easily
• write Lua code which would do the same what Forth code does
  • start small and bring things step by step by continually checking whether regressions are introduced
  • in the process of implementing, think of things which could get dropped

---

Add USB target mode driver based on CTL

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

• Ability to read and understand foreign C code.
• Ability to write C code.
• Hardware that supports USB target (aka gadget) mode, such as Atmel ARM boards

---

Add CD-ROM emulation to CTL

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:

• Ability to read and understand foreign C code.
• Ability to write C code.
• Ability to read and understand T10 (SCSI) specifications

---

bhyve and x86/iommu integration

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:

• Good knowledge of C
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Access to a machine with a recent Intel CPU supporting VT-x and VT-d

---

Instruction caching for bhyve

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:

• Good knowledge of C
• Good knowledge of x86 architecture
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Access to a machine with a recent Intel CPU supporting VT-x and EPT

---

Intel e1000 device model in userspace for bhyve

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

• Good knowledge of C and device drivers.
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Access to a machine with a recent Intel CPU supporting VT-x and EPT

---

bhyve in-kernel timer emulations

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:

• Good knowledge of C
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Access to a machine that supports virtualization.

---

USB device model in userspace for bhyve

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

• Good knowledge of C and device drivers.
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Access to a machine with a recent Intel CPU supporting VT-x and EPT

---

Implement new Xen netfront/netback features

Description

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

• Clean up current drivers.
• Check robustness of current netback implementation.
• Legacy frontend support, check that we can handle old frontends that send packets with 18 frags.
• Split event channels for TX/RX rings.
• Support for multiqueue.
• Benchmarks.

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

• Good knowledge of C and device drivers.
• General understanding of virtualization techniques.
• Ability to read and interpret hardware specs.
• Understanding of FreeBSD net layer and it's API.

• Understanding of XenBus APIs for attach/detach, command/response ring buffers, and interrupt delivery.

---

USB Front-End Driver

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:

• http://wiki.xen.org/wiki/Xen_USB_Passthrough

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

• Good knowledge of C and device drivers.
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Understanding of the USB protocol.
• Understanding of XEN's USB facilities.
• Understanding of FreeBSD USB support code and APIs exported by USB controller drivers.

• Understanding of XenBus APIs for attach/detach, command/response ring buffers, and interrupt delivery.

---

SCSI Front-End Driver

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:

• http://wiki.xen.org/wiki/Paravirtualized_SCSI

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

• Good knowledge of C and device drivers.
• General understanding of virtualization techniques
• Ability to read and interpret hardware specs
• Understanding of the SCSI command model.
• Understanding of XEN's SCSI facilities.
• Understanding of FreeBSD CAM SCSI stack, most specifically the SIM controller driver APIs.

• Understanding of XenBus APIs for attach/detach, command/response ring buffers, and interrupt delivery.

---

VirtualBox shared folder support for FreeBSD guests

Description

• https://github.com/lwhsu/freebsd-vboxfs

• https://www.virtualbox.org/manual/ch04.html#sharedfolders

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

• Ability to read and understand foreign C++ code
• Ability to write C++ code
• Knowledge of the VFS subsystem

---

Ethernet Ring Protection Switching

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

• Be competent in ISO C and FreeBSD kernel-fu.
• Know Ethernet inside and out, or be willing and able.

---

Multiqueue BPF support and other BPF features

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

• Strong knowledge of C.
• Experience with multi-threaded programming.
• Experience with kernel programming.
• Familiarity with the TCP/IP protocol suite.

---

TCP/IP regression test suite

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

• Strong TCP/IP knowledge.

---

ng_aiccu (Sixxs IPv6 tunnel broker aiccu netgraph node)

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

• Good knowledge of C and Layer3.
• Able to understand the FreeBSD network stack.
• Able to read and understand standard documents.
• Internet connectivity and a Sixxs account to test.

---

A New Audit Parsing API

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

• Strong C programming skills.
• Past coursework or reading in the area of computer security.

---

Linux to BSM Conversion Tool

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

• Strong C programming skills.
• Past coursework or reading in the area of computer security.

---

Capsicum application adaptation and core libraries

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:

• Capsicum web page at Cambridge

---

Unattended encrypted kernel crash dumps

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:

• Change crash dump routines to produce encrypted dump on dumpdev.
• Use asymmetric key exchange algorithm for establishing one-time encryption key.
• savecore should add geli or pefs metadata to encrypted dump files while saving (without decryption and requiring user key/password).
• Provide means to facilitate encrypted dump access, i.e. setting up geli providers or mounting pefs.

Requirements

• Strong C programming skills.
• Familiarity with FreeBSD system internals and cryptographic primitives.

---

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

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

• Experience writing KDE applications

---

IPv6 User Land Cleanup

Description

Many userland network utilities do not work correctly with IPv6.

• rpc.statd(8) is not IPv6 clean.
• rpc.rquotad(8) is not IPv6 clean.

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:

• remove/rework the about 200 gethostby*() calls all in the base system and contrib to use getaddrinfo().
• make more code to conditionally compile in INET or INET6 support.
• ...

---

Use CTF data for libkvm

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

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

• Good knowledge of C.

---

Improve Wine support in FreeBSD

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

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

• Knowledge of C.
• Some familiarity with SNMP/MIBs desirable.

---

Port TrueCrypt as a geom_gate userland disk device implementation

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

• Knowledge of C
• Familiarity of how disks and file systems work

---

Userspace pthread mutex lock contention profiling and lock order verification tool

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

• Strong knowledge of C.
• Threading experience.
• Strong debugging skills.

---

FreeBSD port of NetworkManager

Description

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

Requirements

• C programming skills
• Knowledge of the FreeBSD net80211 wireless stack

---

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

Description

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

Requirements

• Perl programming skills
• Knowledge of the FreeBSD system configuration

---

Finish support for compilation of i386 binaries on amd64

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

• C and shell programming skills
• Knowledge of the FreeBSD build and installation infrastructure
• Some knowledge of the gcc internals

---

Improve webcamd support

Description

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

Requirements

• Good knowledge about the C programming language.
• Knowledge about V4L, DVB drivers and the Linux kernel in general.
• Knowledge about the Linux kernel build system and Makefiles.

---

Improve Collation and Multibyte Support in Libc

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

• Good knowledge about the C programming language.

---

Teaching DDB to speak CTF

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

• Strong knowledge of C.
• Experience working with DTrace and debuggers (could be gained while doing the project).
• Ideally, some experience debugging kernels, or at least, system software.

---

Mandatory Access Control

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

• Strong C programming skills.
• Familiarity with OS security policies, including discretionary and mandatory access control.
• Familiarity with concurrent programming techniques.
• Willingness to read the CC/CAPP specification.

---

Path-based file system MAC policy

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

• Strong C programming skills.
• Familiarity with OS security policies, including discretionary and mandatory access control.

---

Security regression tests

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 FreeBSD regression test tree, but they are both incomplete and and inadequate. New tests must be created; existing tests must be completed and updated.

Requirements

• Strong C programming skills.
• High tolerance for writing test code.
• High tolerance for reading API specifications.
• Rigorous and devious mindset.

---

kgdb support for devel/gdb port

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

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

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

• you take 5 simple IPFW/PF rules and work on them so that C can be generated from these. This is nice, since in theory people could start using this stuff with existing rules. It also gives you a limit of functionality (good for staring), so that you don't think about all world problems.
• you design your simple language for packet processing. The idea for this project is to explore hidden possibilities of converting high-level language of FreeBSD firewalls to C. By doing this, we expect to get unprecedented levels of flexibility. You could basically make a programmable firewall.

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:

• pfil_hooks research and understanding where the firewall control points for this are (where firewall hooks are placed in the kernel)
• write 1 simple rule in IPFW
• convert it to KLD by hand
• load KLD and see if it's working
• figure out how much stuff there is in mbuf and which IP/TCP headers are there and which ones we can use for our firewall

• regardless of whether I go via IPFW/PF->C or YourDSL->C, I think I'd limit myself to whatever is in mbuf right now.

• create 5 simple rules
• create 5 KLDs by hand. Make sure they work.

• write a parser HighLevelLang->C and try to make output:

  • human readable
  • as similar as possible to your hand-crafted KLDs.

Pluggable repository support for pkg(8)

Description

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

• The FreeBSD ports tree
• pkgsrc
• macports
• opam
• cpan
• pypy
• gems

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

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:

• Compress memory, rather than paging it out.
• Find identical pages and replace them with copy-on-write mappings to a single physical page.

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:

• Try to identify pages that will compress well and swap them out more aggressively
• Use compressed storage on disk, to reduce swap size and allow faster page-ins for contiguous regions (modern CPUs can decompress lz4-compressed data faster than it can be read even from an SSD).

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

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:

• A hierarchical namespace of services
• Fast one-copy point-to-point messaging
• Broadcast messages with a bloom filter for selecting destinations

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

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)

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.

---

CategoryHistorical