web.archive.org

NetBSD Summer-of-Code Projects 2007

BSD daemonThis page contains a list of concrete suggestions for projects we would like to see applications for Google's Summer-of-Code 2007 for.

If you are interested in working on any of these projects, please contact the developer and/or mailing list referenced next to each item, and possibly answer as many questions from our Project Application HowTo as possible. The interested developers will be glad to respond to you there.

We encourage you to come up with your own suggestions, if you can not find a suitable project here. You can find more project ideas on the NetBSD project ideas page. These are not directly applicable to Summer-of-Code, but may serve as ideas for your own suggestions. You might find other ideas in src/doc/TODO and pkgsrc/doc/TODO.

Deadlines and directions for students' applications to the Google Summer-of-Code can be found on the Google pages.

Project Difficulty
ATA over Ethernet High
Automate regression framework Low
Building Linux Device Drivers with initial focus on webcams and video framework Medium
Create an in-kernel API for "packet classes" High
DHCP client with minimal functionality and size Lowest
DVB drivers and kernel framework Highest
Design and implement a wstablet driver Low
Evaluate, benchmark and optimize samba file server performance High
Flash translation layer Medium
Graceful USB disk detach/reattach High
Hardware monitoring and HAL port High
ISDN NT support and Asterisk integration Medium
Implement Ext3 file system support Medium
Improve LKM support High
Improve support for Ext2 root filesystem Low
Improve/Extend file system resizer Medium
Journaling for FFS Medium
Light weight precision user level time reading Low
NDMP Support Medium
New LPR/LPD for NetBSD Lowest
Package update tool similar to apt-get/yum Medium
Port Nano-X to NetBSD Medium
Port NetBSD/xen to amd64 Highest
Port NetBSD/xen to ia32+PAE Highest
Port ZFS to NetBSD High
Save and restore PF filter state Medium
Secure-PLT - supporting new PLT formats on alpha or powerpc Medium
Support signed (and possibly encrypted) files in Veriexec Medium
Userland daemon for the in-kernel PPPoE server Low
makefs enhancements Low

ATA over Ethernet

Project summary:

AoE is a lightweight alternative to the complex iSCSI, albeit with little security, and limited to the local LAN. NetBSD can be used as an AoE target via aoe-vblade from pkgsrc, but an initiator is needed to retrieve the data from the target. This project is to create an initiator in the NetBSD kernel. The stretch goal is to provide a BSD-licensed (userland) AoE target as well.

Automate regression framework

Project summary:

Rework the NetBSD regression framework to allow automated testing.

NetBSD has a lot of regression tests at various levels collected in src/regress. The tests have been added as problems have been found, but there currently is no easy/automated way to test a given system against all the tests. Other projects, for example gcc, have created out of the box testsuites, that can be run via something simple as “make test”. For a complete operating system, portable to many architectures, this is not possible.

The project is: get as much automation as possible, and optionally design a method how the regression suite could be run in a “build lab” environment on multiple machines of different architecture.

See also PR 23952.

Building Linux Device Drivers with initial focus on webcams and video framework

Project summary:

Linux has a large amount of device drivers for hardware not supported on NetBSD, especially USB devices. Often such drivers have been written based on information derived by protocol sniffing, reverse engineering and such like. This makes the code highly undocumented, and makes the porting effort extremely error prone.

This project should create an emulation layer that would let us recompile the linux source code on NetBSD, and provide a sufficiently complete emulation of the kernel APIs so that device drivers (or at least certain classes) could be used without modifications to their source code.

There is already such a project for FreeBSD which we anticipate will form a basis for a majority of the project. This is a very new pre-alpha project at present.

The FreeBSD project focusses on USB devices and, more specifically, webcams which are historically very poorly supported in all the BSDs. Please see here for a detailed discussion of the problem. All current device support is adhoc; each application has its own userland driver that uses ugen(4) (see mbone/vic in pkgsrc for a prime example; we maintain local patches that add OV511 support). As part of this project, the drivers will present their usual own programming interfaces (where appropriate). For example, most Linux webcam drivers use the video4linux framework. Once again, much of this work is already present in the FreeBSD project.

Project deliverables:

  • A kernel emulation layer for Linux device driver APIs and a method to build unmodified Linux drivers from source as LKMs (because Linux drivers will tend to be GPL we cannot include them in the kernel directly). This layer will focus on a certain class of devices for this project (USB webcams), but must not be designed in such as way as to preclude its use for different classes of drivers in future (e.g. PCI DVB cards).

  • Device drivers for at least 3 webcams for which there are already Linux drivers (cameras can be provided). Use of these webcams should be demonstrated with a suitable client (such as mbone/vic or multimedia/xawtv).

Create an in-kernel API for "packet classes"

Project summary:

Create an in-kernel API for registering "packet classes" and for labeling packets with their class, for special treatment by traffic shapers (ALTQ) and by network interface drivers. With the registration part of the API, ALTQ or a driver registers the names of packet classes it recognizes. For example, ALTQ will register the 'class_name' part of a Class Command - see altq.conf(5). An ethernet NIC with high- and low-priority transmit rings may register classes called 'hipri' and 'lopri'. An 802.11 NIC may register 802.11e traffic categories, BE, BK, VI, VO. Each registration yields a token that is suitable for labeling a packet - i.e., a small amount of data to stick in an mbuf packet header or in an m_tag.

Make PF use the packet-classes API to convert PF tag names — see pf.conf(5) for more about tags — to packet-class tokens, and to label mbufs with the tokens as they exit PF. Make ALTQ extract the packet-class tokens from mbufs and use them to select the packet-scheduling class.

DHCP client with minimal functionality and size

Project summary:

The ISC DHCP client used in NetBSD is a pretty huge application, with rich and complex configurability. This is great for complex scenarios, but not needed for many others.

On the other hand the kernel already can do minimalistic DHCP used in network booting (actually it only does BOOTP). It lacks lease management and options for hook scripts, and can not manage WLAN keys.

This project is to create two alternative minimalistic userland daemons that work together with the existing in-kernel part to build a tiny DHCP client. The first alternative should have no options besides the interface name(s) to use and only does lease management. This binary should not be larger than 10k bytes on 32bit archs - maybe even smaller. The second variant offers scripts to run at a few events (lease acknowledge or expiry) and provides support for interoperating with WLAN keys and helper programs like wpa_supplicant. A valid option for this second part of the project would be to evaluate, cleanup and properly integrate the WIDE project's dhcp client and server.

The kernel dhcp code needs to be modified to be controllable from userland, and a communication channel has to be designed.

Overall target is to create a good-enough dhcp client solution with the minimal possible footprint.

DVB drivers and kernel framework

Project summary:

NetBSD is lacking a framework for DVB (digital video broadcast) receivers. This project should create such a framework and deliver at least one driver for a DVB card making use of the framework.

Further userland work will be needed, for example adapting mythTV to this new kernel API, but this is not part of the project.

A major part of this project is designing the kernel subsystem. There are two alternative approaches: follow the LinuxTV model, or go for a solution similar to DirectShow. The latter seems to be a lot more versatile, but makes the project slightly harder.

Design and implement a wstablet driver

Project summary:

There is no equivalent to the wsmouse (for mice) or wskbd (for keyboards) subsystem for graphics tablets in the generic wscons console driver framework that most NetBSD ports use. Designing and documenting the API, as well as creating at least one hardware driver and interfacing to the X server is the objective of this project.

Evaluate, benchmark and optimize samba file server performance

Project summary:

Samba, the SMB file server, runs fine on NetBSD as is. Since this is a very common network filesharing protocol, performance of the server should be optimized.

It is probably not necessary to go all the way the NFS server code did (i.e. move most protocol handling inside the kernel).

This project is about evaluating possible improvements (use of kqueue, splice/sendfile and similar concepts, adding case independent mount options for the underlying filesystem - probably more to be found during the project), exploring possible implementations, and benchmarking.

Flash translation layer

Project summary:

Implement flash-translation layer to handle bad-block management/wear leveling such that a FFS or LFS filesystem could be placed on above NAND flash chip.

Graceful USB disk detach/reattach

Project summary:

Make NetBSD behave gracefully when a "live" USB/FireWire disk drive is accidentally detached and re-attached by, for example, creating a virtual block device that receives block-read/write commands on behalf of the underlying disk driver. This device will delegate reads and writes to the disk driver, but it will keep a list of commands that are "outstanding," that is, reads that the disk driver has not completed, and writes that have not "hit the platter," so to speak. Following disk re-attachment, the virtual block device replays its list of outstanding commands. A correct solution will not replay commands to the wrong disk if the removable was replaced instead of re-attached. Provide a character device for userland to read indications that a disk in use was abruptly detached.

Open questions: Prior art? Isn't this how the Amiga worked? How will this interact with mount/unmount — is there a use-count on devices? Can you leverage "wedges" in your solution? Does any/most/all removable storage indicate reliably when a block written has actually reached the medium?

Hardware monitoring and HAL port

Project summary:

Almost all operating systems provide a way to notify userland of hardware changes. E.g. a new USB device was connected, a CD-ROM was inserted in a drive, a PCI Express card has been removed, etc. Unfortunately, there is no such functionality in NetBSD, which means that it is not really usable on systems where automation on hardware changes is desired. The most obvious example are desktop systems where one wants hardware to be managed transparently.

In order to implement this notification mechanism, a new device is needed, which we will call devmon from now on. Let's see how devmon would work in ideal world:

  • Communication with userland goes via /dev/drvctl in form of proplib objects — single event will be described in single dictionary. The device should support multiple readers at once, but it doesn't need to warrant every event will be delivered. When an event is dropped, it should signal the fact to the user though. O_NONBLOCK flag should be supported, so should be the select(2) and kqueue(2) interfaces.

  • Device locators (i.e. the interesting bits of information that identify 1. device's position on parent bus; 2. outcome of standard configuration procedure in case the parent bus has any, like vendor/product ID on PCI) are annotated by the parent drivers into a property dictionary of the child device_t.

    Currently locators are represented as integers; when this changes to proplib objects config(8) will need to be adjusted along with many drivers.

    Other problem is that most of the info we care about is currently stored in various <bus>_attach_args structures (short lifetime bus-specific structs), i.e. "most drivers get locators wrong".

Now let's glue the two points together and see how we'd like to use the framework (assuming all of the above has been done):

  • We want to know when a new device appears.

    Since we have all the interesting bits in device_t (this has driver name, parent driver name and bus-specific locators in portable form), we just need code in autoconf(9) to formulate it into a devmon(9) message and link it on event queue consumed by /dev/drvctl. Note no additional changes to device drivers are needed once we've got locators right.

    And note there's a catch — hardware hotplug mechanisms can tell you when a new device arrives, but kernel's struct device really means "device with a driver attached". So we need two different events: "device attached" and "driver attached" in order to use devmon to autoload LKMs when new device appears but is not claimed by any currently-loaded-in-kernel driver. It should be fine to initially ignore this and just handle the "driver" part now.

  • We want to know when a device goes away.

    This is another small change in autoconf(9), same note as above applies.

  • And once we get creative, we might want events for network media changes ("no link on fxp0"), removable media changes ("disc inserted to cd0") and so on. All of them basically mean inventing a new event "message" (dictionary, really) layout and spreading calls to devmon API throughout kernel subsystems of interest.

We'd also like to have a userland daemon watch for events and run actions for us according to a config file — this should provide reasonable expressive power for matching devices and assigning actions to them. The original implementation could do things like "run /etc/foo when sd(4) attaches at something that hangs off usb port N", so it could provide some inspiration. HAL can do this, as described below, but we'd like to have something small and simple in the base system (which means under the BSD license).

A way to simplify the whole project, in case it was too long for SoC would be to simply ignore the complex/lot-of-work parts and come up with a minimal implementation that could just handle "foo0 attach"/"foo0 detach".

There is a preliminary implementation of devmon in kern/29485 and bin/29486 which should be used as part of this project.

Now let's talk about HAL, a utility that should be ported as part of this project.

Freedesktop's HAL is a program that implements a hardware abstraction layer that applications can use to query information about and manipulate the machine's hardware. This currently focuses on hot-plug events (such as the connection of USB devices or insertion of new disks in removable media drives) and power management functionality.

HAL is currently unsupported under NetBSD and this greatly penalizes the overall GNOME and KDE desktops. HAL is required by all those applications that need to access removable media (e.g. Totem, Sound Juicer, Nautilus CD Recorder, etc.) and is also required to automatically mount new drives, a very convenient feature for desktop operating systems.

As described above, NetBSD does not currently provide any hot-plugging interface at the moment, which makes it impossible to port HAL. However, this can be seen as an advantage because we have got the chance to design a new simple and clean interface that needn't be compatible with older stuff.

A reasonable approach to port HAL and integrate it into pkgsrc could be:

  1. Make HAL build and install under NetBSD. The first porting stage is to use stubs for all operating-system specific features so that e.g. a "list all devices" message returns an empty list. Create a package with the results. Even this may seem useless, it allows us to have an installable HAL package and lets us enable HAL support under all packages that support (or require) it.

    Note that there currently is a package for HAL in pkgsrc-wip. It will be imported soon into the mainstream pkgsrc tree with the stubs mentioned above but with no real functionality under NetBSD.

  2. Investigate what information HAL needs about the running operating system, what events it needs to receive and implement a kernel device that is able to provide it. This kernel device is devmon, and ideally it should be built to support all HAL requirements straight from the beginning.

  3. Implement support for the new device into HAL.

ISDN NT support and Asterisk integration

Project summary:

This projects has two subprojects: add support for the NT (network) side of ISDN to the NetBSD ISDN stack and interface ISDN (in NT mode) to the Asterisk PBX, which would allow using existing ISDN PBXes as SIP/VoIP phones, as well as easier testing of new ISDN card drivers.

Previous work in this area can be found at the alternative ISDN driver site.

Implement Ext3 file system support

Project summary:

The Ext2 file system is the de-facto standard, Unix-like file system used on Linux installations. Ext2 does not have journaling capabilities, so Ext3 was built on top of it to add them without breaking compatibility with Ext2. Ext3 is now a stable journaled file system used on lots of Linux installations.

NetBSD currently fully supports the Ext2 file system at the kernel level. Unfortunately there is no support for the new features included in Ext3, although Ext3 file systems can be mounted provided that their journal is clean. It would be very nice if NetBSD had Ext3 file system support because the system could immediately gain a journaled file system as well as compatibility with Linux (imagine having both systems installed on a single partition!). This has, supposedly, lower risk than adding journaling to UFS because Ext3 is already heavily deployed and tested.

Therefore, the aim of this project is to add Ext3 support to the NetBSD kernel accompanied by any userland code required to support it. This shouldn't be too difficult because, as we already mentioned, Ext2 is implemented in the NetBSD kernel (see src/sys/ufs/ext2fs/) and Ext3 is an extension of it.

Improve LKM support

Project summary:

NetBSD currently has support for loadable kernel modules (LKMs), but it is extremely limited and is not usable in the real world. Here are some of its deficiencies alongside the list of deliverables of this project:

  • Lack of an in-kernel linker: In order to load a module, the current modload(8) utility calls the userland linker, ld(1), to link the module with the running kernel. This resolves all external references the module has by using the /dev/ksyms special device. This is problematic because the user must have ld(1) installed in his machine to be able to load modules, something not suitable for installation media, servers, or embedded systems, for example. The first part of this project is to implement an in-kernel linker to avoid all calls to ld(1). FreeBSD has such a loader, so it might be a good idea to port it.

  • Difficulty to build components as modules: At the moment, the kernel is built "monolithically" from a set of sources as described in a configuration file. Modules are built independently, from sources that define how the module behaves and link to the kernel's sources directly; see the src/sys/lkm tree. This is undesirable because these two independent code hierarchies can easily get out of synch, causing all kinds of breakage (undefined or duplicate symbols, for example). It could be better if both the modules and the in-kernel code (depending on the configuration) could be built from a single set of sources, much like what Linux does.

  • Inability to load modules from the boot loader: It'd be good if the kernel could be built with a minimal set of devices in the main binary, even excluding disk drivers. If that were the case, the boot loader would need to be able to load modules into memory and then pass the appropriate information to the kernel so that they could be initialized. This way the kernel could be distributed as a very tiny binary file, alongside a huge set of modules, yet work on any hardware configuration with minimum effort.

  • Lack of a public kernel API: The kernel currently lacks a definition of a public API, which means that modules cannot be easily redistributed because they will most likely not work on any other kernel version than the one they were built on. This is unsuitable for binary-only drivers. A public API should be defined and enforced when building modules. This goes out of the scope of this project, however.

Please note that when adding module support, one has to keep in mind that everything should work from a binary-only distribution (except, of course, rebuilding the modules themselves). The user must not have to rebuild anything on his own to get a module working.

Now, to the way this project should be attacked; that is, the parts in which it can be divided:

  1. The first step is to write the kernel interface to: 1) trigger a module load; 2) trigger a module unload; 3) get a module's symbols; and 4) list loaded modules.

    For the first routine, "trigger a module load", the kernel needs to take a file and load it (the load could be done from userland though), fix up relocation information (implementing the missing in-kernel linker, as explained above) and at last call its on_load method. This needs to be presented to userland applications by means of a syscall.

    The module should be able to indicate whether it needs to be in wired memory or not, as well as any other attribute that may be interesting. Your task will include the design of a data structure that holds this information (a proplist?) and handle it from both sides (the module itself and the kernel).

    This part should be suitable for a SoC project, combined with some other items detailed below.

  2. When we have the basic load/link functionality provided by the previous item, we can start fleshing out things like dependencies, link sets and mucking autoconf to better suit the dynamic nature.

    It is important to state what relocs are supported, what to do about multiple symbols, symbol versioning, etc. Of special interest is to investigate if we need dynamic shared objects (DSOs) or we can use regular objects for modules. We'd like to avoid DSOs if possible, as using them would mean inserting small stubs for functions during the linking stage.

    The implementation of dependency tracking between modules is something that should be developed during SoC too.

  3. At last, one can work on the boot loader, which is rather difficult. We have lots of different methods to boot a kernel, so it would be hard to have something unified over all the ports.

    A possible approach can be to bundle the kernel with the minimum necessary modules in a md(4) image (much like Linux's initrd) so all the boot loader needs to do is boot such an image. This could be quite easy to achieve, requiring no changes to the boot loaders. Unfortunately this removes flexibility from the boot loader, as the kernel will be restricted to load those modules that were bundled within it.

Improve support for Ext2 root filesystem

Project summary:

NetBSD currently has support for the Ext2 file system. Unfortunately, it has some deficiences that make its use unsuitable for a root file system, as detailed below. (Strictly speaking it can be used as such, but it is not easy to do so.)

The Ext2 file system driver in the NetBSD kernel currently supports the use of this file system as the system's root. That is, / can live in an Ext2 partition. However, there is no way to natively boot NetBSD using this mechanism because there is no bootxx_ext2fs boot loader. Similarly there is no support in sysinst to install NetBSD directly onto a Ext2 partition. At the moment the only way to get this to work is to do a manual installation and later use GRUB to boot the kernel instead of the native boot blocks.

But why would this be interesting? Ext2 is a very popular file system. Supporting it as root would mean that you'd install NetBSD inside the same partition as Linux (with some very minor unimplemented features). Similarly, if Ext3 support is added, NetBSD would immediately gain a journaled file system to be used for any partition. Furthermore, this eases cross-development of NetBSD from Linux operating systems.

Implementing bootxx_ext2fs is a matter of adding Ext2 read-only support to the kernel's libsa. This should be rather easy because the on-disk structure of Ext2 is simple enough and there is a lot of useful reference code in src/sys/ufs/ext2fs. Once this is done, creating the boot image is trivial because everything is automatic.

Unfortunately, there are some tricky parts in using bootxx_ext2fs. Ext2 file systems always have their superblock stored at a 1024-byte offset from the start of the file system. This does not leave enough room to install the boot code. A workaround for this shall be found: maybe implementing bootxx_ext2fs is not really needed as long as /boot has Ext2 knowledge and its location is hardcoded in the first boot stage. (This means you will need to deal with installboot's code too.)

Another thing to do as part of this project is to implement a BSD-licensed newfs_ext2fs utility that can be shipped with the base system. Without this program, installing NetBSD into an Ext2 partition is a difficult task, because you cannot format one at the moment; it'd need to be created beforehand by some other system. Once done, sysinst needs to be improved to allow creating and using Ext2 partitions.

At last, fsck_ext2fs should be improved because, after a crash, it detects (and attempts to correct!) far more errors than its Linux counterpart. It can end up destroying some data that ought to be correct in the first place because it thinks is incorrect.

Improve/Extend file system resizer

Project summary:

The NetBSD source tree contains the resize_ffs tool, which allows users to grow or shrink filesystems. This tool needs a regression test suite, general code review, stability improvements and could be ported to FFS2 etc.

Optional items include making it work on FFS2 file systems, or on live filesystems

Journaling for FFS

Project summary:

Solaris UFS (the same filesystem we call FFS) provides for a journaling filesystem with snapshots. Extend FFS/FFS2 similarly; it may even be possible to use a compatible on-disk format.

Light weight precision user level time reading

Project summary:

Design and implement a mechanism that allows for fast user level access to kernel time data structures for NetBSD. For certain types of small data structures the system call overhead is significant. This is especially true for frequently invoked system calls like clock_gettime(), time(), gettimeofday(). With the availability of user level readable high frequency counters it is possible to create fast implementations for precision time reading. Optimizing clock_gettime and alike will reduce the strain from applications frequently calling these system calls and improves timing information quality for applications like NTP. The implementation would be based on a to be modified version of the timecounters implementation in NetBSD.

See also the Paper on Timecounters by Poul-Henning Kamp.

NDMP Support

Project summary:

The NDMP protocol specifies the protocols to perform dumps and backups across a network. There are a number of BSD-licensed XDR specs for NDMPv4, and this project is to provide the necessary functionality to take the RPC invocations and perform the work to save and present the data across the network. This backend to the NDMP protocol will allow NetBSD to act as an NDMP server for communication with third-party applications, such as Netbackup.

New LPR/LPD for NetBSD

Project summary:

The current lpr/lpd system in NetBSD is ancient, buggy, and doesn't support modern printer systems very well. Interested parties would do a from scratch rewrite of a new, modular lpr/lpd system that would support both the old lpd protocol and newer, more modern protocols like IPP, and would be able to handle modern printers easily.

Package update tool similar to apt-get/yum

Project summary:

pkgsrc currently has a set of tools, known as pkg_install, to install, remove and overall maintain the packages installed in a system. Unfortunately, there is no tool to do automated and safe updates of all the installed packages so, generally, this boils down to deinstalling everything in the machine to later install the new versions. As you can imagine, this is unacceptable for production machines or even desktop systems, specially if you are installing from source packages. Doing such updates from binary packages alone is slightly tolerable because they can be made quickly enough (once the binaries are already available). It is clear that we need a tool to do massive updates on a running system with minimum downtime.

Recently, we added package databases to our binary repositories, as described in pkg_summary(5). These databases will make writing an update tool way easier than would be without them.

The aim of this project is to provide a tool that:

  • Retrieves one or more pkg_summary databases.

  • Compares what is installed with what is available.

  • Updates or installs new packages as deduced in the previous stage.

The tool will have to check for conflicts and also library compatibilities when making a decision; note that this information is already available. The tool can be interactive to list what will be done and prompt user to acknowledge, but should allow automation too. The tool should also be able to just indicate what can be updated, download packages only, and search the databases.

Ideally, such a tool could work both from binary and source packages, allowing the user to tune which ones to use. This could make the tool useful for all systems that do not have up-to-date binary packages available, such as slow platforms or non-NetBSD systems (as pkgsrc sees much less use on them). However, this is harder to achieve safely due to all problems that can arise when building software from sources. Therefore, the tool need not support this by the end of the SoC project, but it should be correctly designed to allow future extensions in this direction.

At last, let us note that there was a pkg_install rewrite in process. The new tools have a library ready to be used from C code to handle packages. Depending on its status by the time when the project is started, the update tool might need to be built on top of this library for better integration with the new tools or simply to simplify its coding. If this is not desired at that time, it should be built around the current tools.

Alternatively, one may attempt to port one of the existing tools for other systems (apt-get, yum, urpmi or synaptic to mention some) and make them work with pkgsrc packages through the use of pkg_summary. The downside of this approach is that the tool could not be included in NetBSD because it would not be BSD licensed.

Port Nano-X to NetBSD

Project summary:

The Nano-X Window System aims to bring graphical environments to small devices, where X-Windows is too heavyweight. Porting it to NetBSD involves both kernel and userland work.

Port NetBSD/xen to amd64

Project summary:

Xen itself is available for the amd64 architecture, but NetBSD/xen is only available for i386 (ia32) architecture. It needs to be ported to amd64.

The first step, and probably the hardest, is to run NetBSD/Xen on amd64 as a guest, using a linux/amd64 dom0. For this the initialisation and pmap modules need to be written, and some memory management code adjusted. There is some code available for OpenBSD running on Xen/amd64 which will help with this, and may be reused at least partially. The virtual devices frontend drivers should work without changes.

The second step is to get NetBSD running as domain0. This require the bus_space and bus_dma modules to be adjusted for 64bits. It may also require some work on the xentools30 package. The virtual devices backend drivers should work without changes.

Port NetBSD/xen to ia32+PAE

Project summary:

Xen itself can run in 32bit mode with the PAE extension to access more than 4GB of physical RAM, but NetBSD/xen is only available for i386 (ia32) with 32bit physical addresses. The lack of PAE support is becoming an issue as more and more hosting companies are using ia32+PAE for their Xen offer.

The idea here would be to focus on domU (guest) support, although dom0 support could also be investigated. This should not require modifications outside of the pmap and initialisation modules (and bus_dma if we look at dom0 support).

Xen introduce a third level of indirection between virtual addresses and the addresses used by hardware on the address bus: hardware addresses (addresses that will be in the page table entries) are called "machine addresses"; but guests are expected to use "pseudo-physical" addresses for their memory management; these are converted from/to machine addresses only when dealing with page table entries. In order to support PAE machine addresses will definitively have to be 64bits; whenever pseudo-physical addresses also need to be extended is to be investigated (but it would make things easier if these could be kept at 32bits).

Port ZFS to NetBSD

Project summary:

Sun's ZFS filesystem is available under a non-viral open-source license which is suitable for inclusion in NetBSD as an optional component. The filesystem offers significant reliability and performance benefits over those currently in our source tree.

ZFS has been ported to FreeBSD and some of this work could be reused to speed up porting it to NetBSD. ZFS consists not just of a filesystem but also of a "storage pool" (LVM-like) layer; a port of this layer would be very useful even if the filesystem port were not fully complete by the summer's end. A successful proposal for this project, however, will include a persuasive plan that completes both the storage pool and filesystem layers by summer's end.

The FreeBSD port uses the GEOM logical disk framework, which is not present in NetBSD; we would prefer to have the ZFS logical disk components ported as separate pseudo-disk device drivers both for simplicity and because porting both GEOM and ZFS is much more than one summer of work.

Expect considerable support from the current NetBSD developers for this work, but be prepared to become deeply familiar with NetBSD's filesystem, virtual memory, and device driver interfaces if you are not already. Applicants who already have experience with these components of NetBSD are ideal for this project.

This project, if successfully completed, will provide the student who undertakes it with a very significant body of experience of great commercial value which may well enhance his or her career prospects in the future.

Save and restore PF filter state

Project summary:

Make it possible to save and restore the state of the PF packet filter to disk. The function desired is similar to ipfs(8), however, we would like the saved state to be in a human-readable form. In particular, write the PF NAT & firewall state in the format of PF rules. You will need to augment the PF rules syntax so that it can express properties of PF state such as its TTL. You need to produce a kernel interface for loading the state, and make pfctl's parser understand it. You need to make changes to the in-kernel parts of PF in order to load state. Also, provide for locking/unlocking the PF state tables as they are loaded/dumped.

Secure-PLT - supporting new PLT formats on alpha or powerpc

Project summary:

Currently kernels with options PAX_MPROTECT can not execute dynamically linked binaries on most RISC architectures, because the PLT format defined by the ABI of these architectures uses self-modifying code.

New binutils versions have introduced a different PLT format (enabled with --secureplt) for alpha and powerpc.

These two projects (one for alpha, one for powerpc) are to add support for the new PLT formats introduced in binutils 2.17 and gcc4.1 This will require changes to the dynamic loader (ld.elf_so), various assembly headers, and library files.

Support for both the old and new formats in the same invocation will be required.

Support signed (and possibly encrypted) files in Veriexec

Project summary:

Veriexec is NetBSD's file integrity subsystem. At the moment, it supports only digital fingerprint verification of files due to licensing issues with RSA and DSA implementations.

The goal of the project is to provide support for signed, and possibly encrypted binaries, without adding any non-BSD licensed code to the kernel and/or writing new DSA/RSA implementations.

The direction is to, upon verification of a program's signature, suspend the execution and communicate to a userland agent enough information (the program binary and the signature) to make a decision on whether it is trustable or not -- possibly by invoking GnuPG or similar -- and return an answer back to the kernel, either resuming execution or denying if an error or invalid signature is detected.

Associating a digital signature with a file should be done by either extending the existing Veriexec configuration file format to include a signature (and keeping it in the internal "struct veriexec_file_entry", attached to the file using fileassoc(9) already) or by introducing a naming convention (so that, for example, the signature for "/bin/ls" will be in "/etc/veriexec/bin_ls.sig" or similar) and will be read automatically when Veriexec verifies the signature. Other approaches are also possible.

The mechanism to suspend, dispatch to userland, and resume execution can be borrowed from Systrace (see the message passing interface it uses in src/sys/dev/systrace.c and src/sys/kern/kern_systrace.c). The communication should be done over Veriexec's device file (/dev/veriexec) using proplib(3). Since the userland agent's process should be protected, it is suggested to implement the code to receive messages from the kernel, invoke the signature verification program, and return back the result to the kernel inside init(8) which, at least according to the default security model ("bsd44", traditional NetBSD), is somewhat protected.

Special care should be taken to make sure deadlocks can't happen -- so that execution of the signature verification program won't result in an infinite loop of it trying to evaluate the signature of itself.

Further objectives of the project will be to support management of "trusted entities", to allow signatures by selected keys to operate freely; integration with Veriexec's strict level; support for encrypted files.

All extensions to the Veriexec interface and other modifications to the kernel must be properly documented in the relevant man-pages. All code written must be placed under a loose 2-clause BSD license.

Userland daemon for the in-kernel PPPoE server

Project summary:

NetBSD has a high performance PPPoE implementation (both client and server side), which runs completely inside the kernel. While this is fine for client installations, it is not practical for real server use.

To solve this, a small and simple kernel modification is needed to allow a userland daemon to handle the early parts of a PPPoE session, until IPCP and/or IPv6CP are up - and then pass the complete session on to the kernel. A userland daemon needs to be implemented (or adapted), which should offer radius support.

A potential extension of this project would be to improve the kernel handling of PPPoE sessions for multiple active sessions. The current design relies on only very few sessions existing (resp. pppoe device instances being configured) - and will need a review once a real server could be implemented.

makefs enhancements

Project summary:

Recently, all ports but macppc and mac68k were switched from mkisofs to makefs for creation of bootable install CDs. The goal of this project is to add the missing features to makefs, so these two ports can be switched as well. If time allows, adding additional useful features would be a bonus.

Needed features:

  • Add Apple Type/Creator information to mtree spec file syntax.

  • Create Apple Extensions to ISO9660.

May be needed:

  • Create of hybrid HFS/ISO9660 image.

  • Install HFS boot file (possibly as separate post-processing step)

Additional features:

  • Merge two directory trees (mkisofs's graft points).

  • Create Joliet Extensions.

  • Print size of resulting image.