====== FreeBSD Google Summer of Code 2014 ======
The [[http://www.freebsd.org/|FreeBSD Project]] was pleased to participate in the
[[http://www.google-melange.com/gsoc/homepage/google/gsoc2014|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]]
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@|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|SummerOfCode2013]], [[SummerOfCode2012|SummerOfCode2012]], [[SummerOfCode2011|SummerOfCode2011]], [[SummerOfCode2010|SummerOfCode2010]].
**Looking for inspiration?**
[[BSD_XXI_Manifesto]] (some crazy ideas from Apple-land which %%FreeBSD%% would benefit from)
==== 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 ====
----
===== GSOC2014: Put your topic here =====
| Mentor | %%YourName%%%%|%%mail@ |
| Co-mentor | %%YourName%%%%|%%mail@ |
| Skills | C(advanced, intermediate, beginner) Perl(advanced, intermediate, beginner), Python(advanced, intermediate, beginner), kernel(advanced, intermediate, beginner), computer-architecture(advanced, intermediate, beginner), network(advanced, intermediate, beginner), security(advanced, intermediate, beginner) |
| Mid-term deliverable | Explain what MVP for mid-term is |
| Final deliverable | Explain what MVP for final term is |
==== Description ====
----
===== Machine readable output from userland utilities =====
| Mentor | [[AlfredPerlstein|alfred@]] |
| Co-mentor | [[EitanAdler|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:
* 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) =====
| Mentor | Wojciech A. Koszek [[WojciechKoszek|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 [[WojciechKoszek|wkoszek@]] (FPGA-related ideas) |
| Co-mentor | [[WarnerLosh|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 [[WojciechKoszek|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 [[WojciechKoszek|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:
* 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 =====
| Mentor | [[WarnerLosh|imp@]] |
| Co-mentor | Wojciech A. Koszek [[WojciechKoszek|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 | [[WarnerLosh|imp@]] |
| Co-mentor | Wojciech A. Koszek [[WojciechKoszek|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 [[WojciechKoszek|wkoszek@]] |
| Co-mentor | [[WojciechKoszek|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:
* 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 =====
| Mentor | Wojciech A. Koszek [[WojciechKoszek|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:
- 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) =====
| Mentor | Wojciech A. Koszek [[WojciechKoszek|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:
[[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 =====
| Mentor | [[AndriyGapon|avg@]] |
| Co-mentor | [[AlexanderLeidinger|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**:
* [[http://www.informit.com/store/product.aspx?isbn=0201702452|M. McKusick, G. Neville-Neil, The Design and Implementation of the FreeBSD Operating System (ISBN 0-201-70245-2)]]
* [[http://www.osta.org/specs/pdf/udf260.pdf|UDF 2.60 OSTA Specification]]
* [[http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-167.pdf|Volume and File Structure for Write-Once and Rewritable Media using Non-Sequential Recording for Information Interchange]]
----
===== CPU online/offline project =====
| Mentor | [[JohnBaldwin|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 | [[KrisMoore|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: |
| 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 ====
[[http://forth.org/|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 [[http://ficl.sourceforge.net/ficl.html|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 [[http://ficl.sourceforge.net/upgrading.html|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 =====
| Mentor | Wojciech A. Koszek [[WojciechKoszek|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:
* 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 =====
| Mentor | [[EdwardTomaszNapierala|trasz@]] |
| Co-mentor | [[HansPetterSelasky|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**
* 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 =====
| Mentor | [[EdwardTomaszNapierala|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**:
* 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 =====
| Mentor | [[NeelNatu|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**:
* 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 =====
| Mentor | [[NeelNatu|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**:
* 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 =====
| Mentor | [[NeelNatu|neel@]] |
| Co-mentor | [[PeterGrehan|grehan@]], [[EdMaste|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**
* 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 =====
| Mentor | [[PeterGrehan|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**:
* 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 =====
| Mentor | [[NeelNatu|neel@]] |
| Co-mentor | [[PeterGrehan|grehan@]], [[EdMaste|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**
* 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 =====
| Mentor | [[RogerPau|royger@]] |
| Co-mentor | Wei Liu: |
| 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:
* 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 =====
| Mentor | |
| 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:
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 =====
| Mentor | |
| 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:
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 =====
| Mentor | [[Li-Wen Hsu|lwhsu@]] |
| Co-mentor | [[BernhardFroehlich|decke@]], [[VirtualBox Porting Team|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 ====
* 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 =====
| Mentor | [[BruceSimpson|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**
* 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 =====
| Mentor | [[RobertWatson|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**
* 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 =====
| Mentor | |
| 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**
* Strong TCP/IP knowledge.
----
===== ng_aiccu (Sixxs IPv6 tunnel broker aiccu netgraph node) =====
| Mentor | [[BjoernZeeb|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**
* 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 =====
| Mentor | [[RobertWatson|rwatson@]] |
| Co-mentor | [[TrustedBSD audit mailing list|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**
* Strong C programming skills.
* Past coursework or reading in the area of computer security.
----
===== Linux to BSM Conversion Tool =====
| Mentor | [[RobertWatson|rwatson@]] |
| Co-mentor | [[TrustedBSD audit mailing list|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**
* Strong C programming skills.
* Past coursework or reading in the area of computer security.
----
===== Capsicum application adaptation and core libraries =====
| Mentor | [[RobertWatson|rwatson@]] |
| Co-mentor | [[BenLaurie|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:
* [[http://www.cl.cam.ac.uk/research/security/capsicum|Capsicum web page at Cambridge]]
----
===== Unattended encrypted kernel crash dumps =====
| Mentor | [[GlebKurtsou|gleb@]] |
| Co-mentor | [[JohnMarkGurney|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:
* 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 =====
| Mentor | [[ColinPercival|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 [[http://developer.berlios.de/projects/facund|berlios]]; the QT frontend could maybe share common functions/classes and design ideas.
**Requirements**
* Experience writing KDE applications
----
===== IPv6 User Land Cleanup =====
| Mentor | |
| 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.
* 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 =====
| Mentor | [[JohnMarkGurney|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 | [[RobertWatson|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 [[LibNetstat|wiki]].
**Requirements**
* Good knowledge of C.
----
===== Improve Wine support in FreeBSD =====
| Mentor | [[KrisMoore|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 | [[ShteryanaShopova|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|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|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 =====
| Mentor | [[IvanVoras|ivoras@]] |
| Co-mentor | [[JohnMarkGurney|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 ====
[[http://www.truecrypt.org/|TrueCrypt]] is a popular cross-platform on-the-fly disk encryption software. Recently [[http://leaf.dragonflybsd.org/mailarchive/kernel/2011-07/msg00028.html|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 =====
| Mentor | [[JeffRoberson|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**
* Strong knowledge of C.
* Threading experience.
* Strong debugging skills.
----
===== FreeBSD port of NetworkManager =====
| Mentor | [[JoeMarcusClarke|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**
* C programming skills
* Knowledge of the %%FreeBSD%% net80211 wireless stack
----
===== Fix FreeBSD support in GNOME's system-tools-backends =====
| Mentor | [[JoeMarcusClarke|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**
* Perl programming skills
* Knowledge of the %%FreeBSD%% system configuration
----
===== Finish support for compilation of i386 binaries on amd64 =====
| Mentor | [[KonstantinBelousov|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**
* C and shell programming skills
* Knowledge of the %%FreeBSD%% build and installation infrastructure
* Some knowledge of the gcc internals
----
===== Improve webcamd support =====
| Mentor | [[HansPetterSelasky|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 [[http://www.selasky.org/hans_petter/video4bsd/|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 =====
| 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**
* Good knowledge about the C programming language.
----
===== Teaching DDB to speak CTF =====
| Mentor | [[RobertWatson|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**
* 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 =====
| Mentor | [[RobertWatson|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**
* 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 =====
| Mentor | [[RobertWatson|rwatson@]] |
| Co-mentor | [[TrustedBSD discuss mailing list|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 ====
* Strong C programming skills.
* Familiarity with OS security policies, including discretionary and mandatory access control.
----
===== Security regression tests =====
| Mentor | [[RobertWatson|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/|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 =====
| Mentor | |
| 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 | [[EdMaste|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 [[WojciechKoszek|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:
* 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) =====
| Mentor | [[BaptisteDaroussin|bapt@]] |
| Co-mentor | |
| 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):
* 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 =====
| Mentor | [[DavidChisnall|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:
* 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 =====
| Mentor | [[DavidChisnall|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:
* 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 =====
| Mentor | [[JulioMerino|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 [[TestSuite|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:
- Ensuring that every test case is clearly separated in its own test case definition as provided by ATF.
- 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 [[https://github.com/yaneurabeya/freebsd|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 | [[BaptisteDaroussin|bapt@]] |
| Co-mentor | [[VsevolodStakhov|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.
----
{{tag>Historical}}