The OpenBSD Foundation

The OpenBSD Foundation Ideas List - GSOC 2014

The OpenBSD Foundation is pleased to have been accepted as a mentoring organization for Google Summer of Code 2014. Our ideas list is below. If you are considering applying for GSOC and are interested in anything below please get in contact with the listed prospective mentor(s).

  • Project: Port Capsicum to OpenBSD.

    Brief explanation: Capsicum is a lightweight capability API for sandboxing and privilege separation. This project involves becoming familiar with the existing Capsicum API and implementation, porting and/or reimplementing them on OpenBSD, and modifying existing OpenBSD applications to make use of Capsicum.

    Expected results: Enable OpenBSD applications to use Capsicum for privilege separation.

    Knowledge prerequisite: Strong understanding of C and Posix (e.g., file descriptors, processes, system calls), attentiveness to security and correctness issues.

    Mentor: Matthew Dempsky, Damien Miller

  • Project: Implement centralized dhclient daemon.

    Brief explanation: Systems with multiple network interfaces could greatly benefit from a single coordinating dhclient daemon to mediate between the individual dhclient processes responsible for a single interface. In particular consolidating the routing information and resolv.conf components from the dhcp information provided from mulitple interfaces is very desirable.

    Expected results: A daemon integrated into the normal OpenBSD daemon infrastructure that improves coordination between individual dhclient processes.

    Knowledge prerequisite: C.

    Mentor: Ken Westerback

  • Project: Implement dhcp6 client.

    Brief explanation: OpenBSD currently lacks any dhcp6 client in the base system.

    Expected results: A working dhcp6 client.

    Knowldge prerequisite: C.

    Mentor: Ken Westerback

  • Project: Implement an OpenBSD style privilege separated dhcp6d server.

    Brief explanation: OpenBSD currently lacks a dhcp6d server in the base system.

    Expected results: A working dhcp6d server.

    Knowledge prerequisite: C, yacc.

    Mentor: Ken Westerback Matthieu Herrb

  • Project: Replace dhcpd and dhclient parsing code with yacc parser.

    Brief explanation: The base dhcpd and dhclient programs use hand rolled parsing code that was possibly at one time a proper yacc parser. But the code has mutated into a difficult to maintain mess.

    Expected results: A yacc parser for dhcpd and dhclient.

    Knowledge prerequisite: C, yacc.

    Mentor: Ken Westerback

  • Project: Implement GPT support.

    Brief explanation: OpenBSD currently lacks any support for GUID Partition Tables.

    Expected results: A Utility or utilities to partition disks using GPT, and support in at least the OpenBSD amd64 architecture for booting from a GPT partitioned disk.

    Knowledge prerequisite: C, assembler.

    Mentor: Ken Westerback

  • Project: Port Valgrind to OpenBSD.

    Brief explanation: A port of the Valgrind system would provide a valuable debugging and profiling tool for the OpenBSD community.

    Expected results: An OpenBSD port of the main Valgrind tools for at least one architecture.

    Knowledge prequisite: GCC, C, assembler.

    Mentor: Marc Espie, Miod Vallat

  • Project: Port llvm/clang sanitizer to OpenBSD.

    Brief explanation: A port of the llvm/clang { address, thread, memory } sanitizer would provide a valuable debugging and profiling tool for the OpenBSD community.

    Expected results: An OpenBSD port of the llvm/clang sanitizer for at least one architecture.

    Knowledge prequisite: llvm/clang, C.

    Mentor: Damien Miller

  • Project: FIB route aggregation for OpenBGPd.

    Brief explanation: With the default-free zone reaching 500,000 prefixes it is desirable to aggregate these prefixes by next-hop. The aggregates can then be inserted into the forwarding information base (FIB, i.e. the kernel routing table). This project involves designing and implementing an efficient algorithm (both in time and space) to calculate aggregates while there are constant updates / withdraws from BGP peers, some sort of rationale why that algorithm is correct, a regression test for the algorithm and finally implementing it in OpenBGPd.

    Expected results: Aggregated routes in the kernel routing table.

    Knowledge prerequisite: Strong understanding of C, Classless Inter-Domain Routing (CIDR), Border Gateway Protocol (BGP).

    Mentor: Florian Obser

  • Project: Port X.Org nouveau driver to OpenBSD.

    Brief explanation: Support for more X drivers is always needed to allow OpenBSD to work with the widest possible range of hardware.

    Expected results: A working nouveau driver for OpenBSD.

    Knowledge prerequisite: X, C, KMS, TTM, graphics.

    Mentor: Matthieu Herrb

  • Project: Create Linux evdev compatible input layer for wscons.

    Brief explanation: evdev support will open the road for enabling multi-touch support in X and a future Wayland port.

    Expected results: A working evdev compatible input layer in wscons.

    Knowledge prerequisite: X, C.

    Mentor: Matthieu Herrb

  • Project: Initial integration of Hammer2 filesystem in OpenBSD.

    Brief explanation: Support for an improved filesystem such as Hammer2 would be of great interest to many in the OpenBSD community. The barriers to integrating Hammer2 are expected to be high, but how high is currently unknown.

    Expected results: A proof of viability or impossiblity of porting Hammer2, with detailed exploration of exactly what the barriers would be for full integration.

    Knowledge prerequisite: C, file systems.

    Mentor: Bob Beck

  • Project: Reimplement wdc(4) using the atascsi subsystem.

    Brief explanation: Elimination of wildly unsupportable wdc(4) and related components would provide substantial improvements to support for cfcard and intel ide devices.

    Expected results: A working replacement for the wdc(4) and related components.

    Knowledge prerequisite: C, device drivers.

    Mentor: David Gwynne

  • Project: Implement a flat device table (fdt) tool chain.

    Brief explanation: The flat device table (fdt) mechanism is used in a various SOC implementations and OpenBSD currently lacks a tool chain to create, manipulate and explore the required structures.

    Expected results: A working fdt tool chain.

    Knowledge prerequisite: C, device drivers.

    Mentor: David Gwynne

  • Project: Implement a boot loader for ARM systems.

    Brief explanation: Implement a proper OpenBSD style boot loader for ARM systems.

    Expected results: A working boot loader for at least one supported ARM platform, preferably Beaglebone Black.

    Knowledge prerequisite: C, device drivers, ARM.

    Mentor: David Gwynne

  • Project: Implement LLVM/Clang-based static analysis checker.

    Brief explanation: LLVM/Clang exposes the whole AST to a developer enabling to create tools based on it. Recently OpenBSD removed lint(1) -- a legacy tool which uses static analysis to find potential security bugs. This project involves creating a more useful LLVM/Clang-based static analysis checker which finds constructs which are deemed unsafe in OpenBSD. Such unsafe constructs are currently documented in manual pages under CAVEATS sections.

    Expected results: LLVM/Clang-based static analysis checker catching constructs which are deemed unsafe in OpenBSD.

    Knowledge prerequisite: Strong understanding of C and static analysis.

    Mentor: Martynas Venckus

  • Project: Hardware floating point for OpenBSD/armv7.

    Brief explanation: Currently on OpenBSD/armv7 floating point operations are emulated in libc using softfloat, although the hardware does support hardware floating point. This project involves bringing hardware floating point support in OpenBSD/armv7 userland.

    Expected results: Hardware floating point support in OpenBSD/armv7 userland.

    Knowledge prerequisite: Understanding of the ARM architecture and floating point.

    Mentor: Martynas Venckus

  • Project: Asynchronous USB transfer submission from userland.

    Brief explanation: Extend the existing interface exposed by ugen(4) and usb(4) and used mainly though libusb, or design a new one, to be able to submit USB transfers asynchronously.

    Expected results: A working interface supporting at least control, bulk and interrupt transfers.

    Knowledge prequisite: C, USB, device drivers.

    Mentor: Martin Pieuchot

  • Project: Add sdmmc stack to sys/lib/libsa.

    Brief explanation: One of most problematic missing part for having a working boot block on armv7 is that there is no minimal sdmmc stack code in sys/lib/libsa.

    Expected results: A working sdmmc stack in sys/lib/libsa.

    Knowledge prequisite: C, device drivers, ARM.

    Mentor: Sylvestre Gallon, Miod Vallat

  • Project: Provide bsd-licenced, os-agnostic, dbus-api compatible systemd-{hostnamed,timedated,localed,logind} replacements.

    Brief explanation: More and more desktop-level applications now depend on apis provided by linux's systemd. We need to have an equivalent to keep up with them.

    Expected results: Working & seamless integration of those components as ports.

    Knowledge prerequisite: C, D-BUS, perl.

    Mentor: Landry Breuil, Antoine Jacoutot

  • Project: Fix Webkit2 API on *BSD.

    Brief explanation: The split-process rendering API in Webkit available since 2.0 doesn't work on *BSD.

    Expected results: Working API within Webkit, with patches in the ports-tree, and the same code properly integrated upstream.

    Knowledge prerequisite: C, IPC.

    Mentor: Landry Breuil, Antoine Jacoutot

  • Project: Proper WebRTC integration in Mozilla.

    Brief explanation: The WebRTC API within Firefox is not yet fully functional nor stable on OpenBSD. Sound integration not finished, testing coverage very low.

    Expected results: WebRTC working & enabled by default within Firefox in OpenBSD's ports-tree. Patches properly integrated upstream.

    Knowledge prerequisite: C, IPC.

    Mentor: Landry Breuil

  • Project: Replace existing four PPP implementations with enhanced pipex.

    Brief explanation: Three of the four existing PPP implementation (ppp, pppoe, sppp) should be removed and any functionality from them that is currently missing from pipex should be added to pipex.

    Expected results: A pipex implementation that does everything ppp, pppoe and sppp do.

    Knowledge prerequisite: C, device drivers, PPP.

    Mentor: David Gwynne

  • Project: A bug tracking system that integrates with sendbug(1) and doesn't suck dead bunnies through bent straws.

    Brief explanation: OpenBSD bugs are sent in a formatted way to a public mailing list via the sendbug(1) utility. A long time ago we had gnats integration that would file these bugs and allow developers to track them and close them. security issues with this code forced us to discontinue this practice. A replacement would be nice, that was accessible to developers with a simple interface but not hosted on the project's critical infrastructure, and which took its input from sendbug in an intelligent way.

    Expected results: A bug tracking system that integrates with sendbug(1) and only drives half the developers batsh**t crazy (with the other half willing to use it) would be a resounding success.

    Knowledge prerequisite: *secure* *simple* web applications, data integration, and an ability to keep things simple and appealing to geeks that just want the job done without dancing baloney.

    Mentor: Bob Beck, Todd Miller

  • Project: Infrastructure for integrating OpenBSD Ports and module installation frameworks.

    Brief explanation: OpenBSD Ports contain many small ports for Ruby gems, CPAN modules and so on. Those ports are mostly simple "wrappers" that rely on corresponding port modules. There are a few problems with this design: <1) in OpenBSD Ports, it's needed to manually duplicate version requirements from upstream package; 2) maintaining a full port structure for each small upstream package consumes too much time from maintainers.

    Expected results: Fully-automated process of creating and updating ports for upstream modules packages.

    Knowledge prerequisite: C, perl.

    Mentor: Vadim Zhukov, Marc Espie

  • Project: OS-agnostic NetworkManager analog.

    Brief explanation: NetworkManager is a de-facto standard on Linux desktops. Unfortunately, it's highly Linux specific, and has some design flaws, too. The idea is to create an easy-to-use GUI that tries to implement as little network management logic itself as possible; any missing features should be implemented as separate utilities/services that integrate into the OS.

    Expected results: Easy-to-use network management GUI working on OpenBSD at least. It should be able to notify you about Wi-Fi networks, allow you to choose and set up one, and set up and monitor VPNs.

    Knowledge prerequisite: C, X, networking.

    Mentor: Vadim Zhukov

  • Project: Act on accelerometer input in laptop.

    Brief explanation: Some laptops have integrated accelerometer sensors, e.g., Lenovo ThinkPads has aps(4). The sensor data could be used to put the laptop in less fragile state; e.g., the HDD heads could be parked.

    Expected results: HDD heads should be parked automatically in 0,3sec or less if laptop is being dropped.

    Knowledge prerequisite: At least one laptop with an accelerometer (if the latter is not support under OpenBSD, it will be needed to implement a driver for it, too).

    Mentor: Vadim Zhukov

  • Project: Add milters support in smtpd.

    Brief explanation: smtpd has a framework for writing session and content filters. The idea is to write a filter that provides a bridge between Sendmail's "Milter" API and smtpd's own framework. We've done a bit of similar work by writing Perl and Python bindings, the milter one would be similar but trickier.

    Expected results: a "filter-milter" calls an unmodified milter and allows it to run on top of smtpd, which will possibly require also extending slightly our filters framework.

    Knowledge prerequisite: C, IPC.

    Mentor: Gilles Chehade, Eric Faurot

  • Project: Port Linux SECCOMP-bpf sandbox to OpenBSD.

    Brief explanation: Linux recently added an API for discretionary sandboxing using small programs written in the bpf(4) bytecode format to inspect system calls and their arguments. This project would port this API to OpenBSD.

    Expected results: A working port of SECCOMP-bpf that is API compatible with Linux. A set of regression tests (written or ported). Successful sandboxing of OpenSSH and Chromium using their existing SECCOMP-bpf code (adjusted for differences between platforms).

    Knowledge prerequisite: Familiarity with bpf(4), the Linux SECCOMP sandbox and/or the OpenBSD kernel.

    Mentor: Damien Miller

  • Project: Better integration of pseudo-drivers in the network stack.

    Brief explanation: At lot if not all the network pseudo-drivers, carp(4), trunk(4), bridge(4), etc are integrated in OpenBSD's network stack using a lot of hackish #ifdef's which are not always justified, leading in some case to useless lookups or memcopys. This project would be to redesign/ improve the integration of such drivers in the stack.

    Expected results: A set of patches to improve the current integration of such drivers.

    Knowledge prerequisite: C, device driver, Networking, IP, Ethernet, CARP.

    Mentor: Martin Pieuchot, David Gwynne

  • Project: Modernize dhcpd daemon to OpenBSD standards.

    Brief explanation: Enhance the current dhcpd daemon to bring it up to current OpenBSD standards, by adding things like socket support for remote clients and a separate control program to enable live database and configuration reloads. A survey of other dhcpd products to identify and then implement missing functionality would be part of the work.

    Expected results: A working dhcpd daemon with most if not all features of a current OpenBSD daemon, with any missing modern dhcp functionality added.

    Knowledge prerequisite: C, dhcp.

    Mentor: Ken Westerback

  • Project: Design and implement network configuration daemon.

    Brief explanation: Gathering the disparate network configuration mechanisms into one daemon that can provide coherence and a single point of control would greatly enhance the usefulness of OpenBSD in complex networking setups. The current mechanisms that are candidates for assimilation include dhcp, dhcp6. rtsol, and ifconfig. Similar efforts are underway on many os projects, which will serve as useful sources of ideas.

    Expected results: A single daemon subsuming at least two previous configuration mechanisms with a clear design for further assimilation.

    Knowledge prerequisite: C, kernal networking interfaces, dhcp.

    Mentor: Ken Westerback, Henning Brauer

  • Project: Java 8 on OpenBSD.

    Brief explanation: The Java language remains an important part of many enterprises' IT strategies. OpenBSD has had Java in its ports tree since Java 1.3, but has stopped at 1.7. The project is to adapt JDK 1.8's new build system into the OpenBSD Ports way of doing things. If time remains after this is completed, it can be used on updating other tools (IDEs) and applications to levels which work for 1.8.

    Expected results: A working JDK 1.8 properly integrated with the OpenBSD ports tree.

    Knowledge prerequisite: Strong understanding of C, Java. Access to a fast computer running OpenBSD/amd64 and/or OpenBSD/i386.

    Mentor: Ian Darwin, Antoine Jacoutot, Jasper Lievisse Adriaanse

  • Project: Implement the rapid DHCP lease process described in RFC 4436.

    Brief explanation: With the demise of dhclient-script, it should now be possible to obtain and bind leases far faster than the current norm. Techniques for doing this are described in RFC 4436 and already implemented in various OS's. This would significantly improve the user experience of resume and moving between networks.

    Expected results: A RFC 4436 compliant dhclient that obtains and binds leases far faster than the current code.

    Knowledge prerequisite: Strong understanding of C, DHCP, networking.

    Mentor: Ken Westerback

  • Project: Implement BFD support as described in RFC 5880 and RFC 5881.

    Brief explanation: Bidirectional Forwarding Detection is a protocol to actively detect faults in the forwarding path between two routers. In OpenBSD BFD will extend the current link-state tracking to do end to end test between two hosts. This project involves writing a basic BFD implementation which in a second step will be integrated into the network stack. Finally interoperability with various other systems needs to be tested.

    Expected results: A working BFD implementation for OpenBSD.

    Knowledge prerequisite: Strong understanding of C, Networking.

    Mentor: Claudio Jeker, Henning Brauer