Computer Laboratory

CTSRD

Part II, Part III, and ACS student project ideas


This page documents dissertation and research project ideas based on CTSRD-derived research for University of Cambridge Computer Laboratory students. There are, of course, many other interesting projects that might be done in related areas, and you should feel to talk to us about these as well. Please contact the listed potential supervisor, or Dr Robert Watson, for further information.

Capsicum-related project ideas

    Capsicum Support in GNUstep

    GNUstep is an implementation of the APIs from the OpenStep specification and later from Apple's Cocoa. This project will involve modifying the framework to make use of Capsicum, a simple set of capability APIs for FreeBSD. There are several steps:

    • Modify NSWorkspace to read a plist describing required services from an application or tool's property list and ensure that they have access to them, then call cap_enter before spawning. This part requires rtld to support sandboxed-on-launch code. If this support is not finished, then a first approximation can be achieved by calling cap_enter() from NSApplicationMain().
    • Implement a file chooser service that will pass file and directory descriptors to applications that try to use the standard open / save dialogs.
    • Ensure that the distributed notification centre and pasteboard server connections are open before entering the sandbox.

    At this stage, applications should be useable with capsicum with some small modifications. There are several additional small changes that could make the porting easier:

    • Modify NSFileWrapper to use openat() and friends.
    • Create an NSString subclass that carries a file descriptor for a base path as an instance variable and allows all of the standard path modification operations to work relative to this.
    • Maintain a dictionary mapping paths to directory descriptors, so that attempts to open a file with NSFileHandle or NSFileWrapper will use openat() via this mechanism.

    Evaluation should include some example applications running in sandboxes, a comparison with the MAC-based sandboxing on OS X, and ideally an example of using Distributed Objects to implement privilege separation in an existing application.

    Prerequisites: Knowledge of Objective-C, UNIX programming.

    Point of contact: David Chisnall

    Further Reading:

More to follow shortly.

TESLA-related project ideas

TESLA realtime and probability distributions

This project depends on an ongoing research project and will involve working with the research team.

Temporally Enhanced Security Logic Assertions (TESLA) introduce C-language extensions for inline temporal assertions and automata validation, which in turn drive compiler-generated runtime instrumentation and validation of temporal effects. However, strict sequence-based properties are not the only type of temporal properties that may be of interest: we are also interested in realtime effects, such as validating assertions of realtime behaviour in protocols, and distribution effects over time, in which sampled values take on desired properties (e.g., randomness and monotonicity). This project would extend the TESLA framework to allow these properties to be declared and continuously validated during program execution.

Prerequisites: strong working knowledge of the C programming language, and an interest in both compilers and low-level system software, such as operating system kernels and network daemons.

Points of contact: Robert Watson, Jon Anderson

More to follow shortly.

BERI-related project ideas

To follow shortly.

CHERI-related project ideas

    CHERI GC

    This project depends on an ongoing research project and will involve working with the research team. It is probably best suited to a masters student.

    The CHERI (Capability Enhanced RISC Instructions) architecture is a MIPS-based softcore containing a capability coprocessor. Capabilities, in this setting, are fat pointers that contain a base, a range, and a set of permissions and flags. The architecture provides tagged memory, distinguishing between memory storing capabilities and memory containing only data. All memory accesses must go via a capability and so interior pointers stored in normal memory are just offsets.

    This project should implement a garbage collector that takes advantage of the ability to accurately identify memory. There are a lot of potential activities within this project. The simplest would be a single-scan for address space reclamation. In typical use, C code on CHERI will never reuse address space. A 64-bit virtual address space provides a lot of scope for this, but it will eventually be exhausted, especially for sandboxed libraries that are in a smaller address space within a larger system. Being able to identify address ranges that have no capabilities pointing to them is useful for this, allowing safe address space reuse.

    A more complete solution would implement a garbage collector that could identify the complete set of reachable memory. Again, this could initially be a stop-the-world mark-and-sweep collector (stopping the world for a mark, resuming for a sweep) and then allowing the unreferenced memory to be recycled.

    Possible extensions include:

    • Integration with the host OS to cache the locations of pointers from swapped regions, so they don't have to be paged back in, and to identify mapped regions of virtual address space that may contain pointers.
    • Copying collection, where capabilities for an object are all identified, all marked as read-only, the object copied, and then the capability's base addresses updated.
    • Generational collection, where capabilities for older objects are marked read-only (immutable) so that they do not have to be re-scanned. The trap handler should move them into a younger generation if they are modified.

    Prerequisites: Knowledge of C, graph theory, virtual memory, MIPS assembly.

    Point of contact: David Chisnall

    Further reading:

More to follow shortly.

SOAAP-related project ideas

To follow shortly.