Project: gVisor (Runtime / Container Runtime)
File: gsoc-2021-ideas.md

This is a collection of project ideas for . These projects are intended to be relatively self-contained and should be good starting projects for new contributors to gVisor. We expect individual contributors to be able to make reasonable progress on these projects over the course of several weeks. Familiarity with Golang and knowledge about systems programming in Linux will be helpful. If you're interested in contributing to gVisor through Google Summer of Code 2021, but would like to propose your own idea for a project, please see our for areas of development, and get in touch through our or ! Estimated complexity: easy This project involves implementing the syscall. gVisor currently supports manipulation of namespaces through the `clone` and `unshare` syscalls. These two syscalls essentially implement the requisite logic for `setns`, but there is currently no way to obtain a file descriptor referring to a namespace in gVisor. As described in the `setns` man page, the two typical ways of obtaining such a file descriptor in Linux are by opening a file in `/proc/[pid]/ns`, or through the `pidfd_open` syscall. For gVisor, we recommend implementing the `/proc/[pid]/ns` mechanism first, which would involve implementing a trivial namespace file type in procfs. Estimated complexity: medium Implement in gVisor, which is a filesystem event notification mechanism. gVisor currently supports `inotify`, which is a similar mechanism with slightly different capabilities, but which should serve as a good reference. The `fanotify` interface adds two new syscalls: `fanotify_init` creates a new notification group, which is a collection of filesystem objects watched by the kernel. The group is represented by a file descriptor returned by this syscall. Events on the watched objects can be retrieved by reading from this file descriptor. `fanotify_mark` adds a filesystem object to a watch group, or modifies the parameters of an existing watch. Unlike `inotify`, `fanotify` can set watches on filesystems and mount points, which will require some additional data tracking on the corresponding filesystem objects within the sentry. A well-designed implementation should reuse the notifications from `inotify` for files and directories (this is also how Linux implements these mechanisms), and should implement the necessary tracking and notifications for filesystems and mount points. Estimated complexity: hard `io_uring` is the latest asynchronous I/O API in Linux. This project will involve implementing the system interfaces required to support `io_uring` in gVisor. A successful implementation should have similar relatively performance and scalability characteristics compared to synchronous I/O syscalls, as in Linux. The core of the `io_uring` interface is deceptively simple, involving only three new syscalls: `iouringsetup(2)` creates a new `io_uring` instance represented by a file descriptor, including a set of request submission and completion queues backed by shared memory ring buffers. `iouringregister(2)` optionally binds kernel resources such as files and memory buffers to handles, which can then be passed to `io_uring`

Pre-registering resources in this way moves the cost of looking up and validating these resources to registration time rather than paying the cost during the operation. `iouringenter(2)` is the syscall used to submit queued operations and wait for completions. This is the most complex part of the mechanism, requiring the kernel to process queued request from the submission queue, dispatching the appropriate I/O operation based on the request arguments and blocking for the requested number of operations to be completed before returning. An `io_uring` request is effectively an opcode specifying the I/O operation to perform, and corresponding arguments. The opcodes and arguments closely relate to the corresponding synchronous I/O syscall. In addition, there are some `io_uring`-specific arguments that specify things like how to process requests, how to interpret the arguments and communicate the status of the ring buffers. For a detailed description of the `io_uring` interface, see the by the `io_uring` authors. Due to the complexity of the full `io_uring` mechanism and the numerous supported operations, it should be implemented in two stages: In the first stage, a simplified version of the `iouringsetup` and `iouringenter` syscalls should be implemented, which will only support a minimal set of arguments and just one or two simple opcodes. This simplified implementation can be used to figure out how to integrate `io_uring` with gVisor's virtual filesystem and memory management subsystems, as well as benchmark the implementation to ensure it has the desired performance characteristics. The goal in this stage should be to implement the smallest subset of features required to perform a basic operation through `io_uring`s. In the second stage, support can be added for all the I/O operations supported by Linux, as well as advanced `io_uring` features such as fixed files and buffers (via `iouringregister`), polled I/O and kernel-side request polling. A single contributor can expect to make reasonable progress on the first stage within the scope of Google Summer of Code. The second stage, while not necessarily difficult, is likely to be very time consuming. However it also lends itself well to parallel development by multiple contributors. Estimated complexity: hard Linux provides two alternate message queues: and . gVisor currently doesn't implement either. Both mechanisms add multiple syscalls for managing and using the message queues, see the relevant man pages above for their full description. The core of both mechanisms are very similar, it may be possible to back both mechanisms with a common implementation in gVisor. Linux however has two distinct implementations. An individual contributor can reasonably implement a minimal version of one of these two mechanisms within the scope of Google Summer of Code. The System V queue may be slightly easier to implement, as gVisor already implements System V semaphores and shared memory regions, so the code for managing IPC objects and the registry already exist.