HackMD
copy-paste this and fill contents:
Template [template]
Author: Firstname Lastname
Owner: TODO
Tech lead: TODO
Estimated duration: TODO
Priority: TODO
Rationale for topic relevance
[Please fill in here]
Summary of objectives
- [Please fill in here]
Prerequisites / dependencies
- [Please fill in here]
Notes
- [Please fill in here]
Driver Probing Framework
Author: Michalis Pappas
Owner: Răzvan Deaconescu
Tech lead: Michalis Pappas
Estimated duration: 4 months
Priority: medium
Rationale for topic relevance
Register driver corresponding to device.
Probe for devices at boot or when connected.
Notes
- Implement using
ukbus.
Memory Tagging Extension
Author: Michalis Pappas
Owner: Hugo Lefeuvre
Tech lead: Michalis Pappas
Estimated duration: 2 weeks
Priority: medium
Rationale for topic relevance
Add support for MTE (Memory Tagging Extension) to tag memory on ARM64.
Notes
- PR available, needs to be reviewed
ukcpuid
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated duration: 3 months
Priority: medium
Rationale for topic relevance
Query CPU features early in the boot process to use in later phases, such as when invoking hardware randomization.
Summary of objectives
- Provide arch-level API (
ukcpuid) - Add implementation for x86
- Add implementation for ARM
Notes
- PR available, requires reviews and updates
Hardware Randomization
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Marc Rittinghaus
Estimated duration: 3 months
Priority: medium
Rationale for topic relevance
Hardware randomization is required for TRNG (True Random Number Generators).
Summary of objectives
- Provide arch-level random API (
ukarch_random) - Add hardware RNG for ARM
- Add hardware RNG for x86
Prerequisites / dependencies
Notes
ukarch_randomPR is available, waiting for review- PR on x86 hardware randomization, requires updates
procfs Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated duration: 2 months
Priority: medium
Rationale for topic relevance
Applications built for Linux make use of proc filesystem entries.
With procfs support, more applications can be ported.
Notes
- procfs support will use ukstore entries, where possible / available.
Musl Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated duration: 1 month
Priority: high
Rationale for topic relevance
Add support for Musl as standard C library in Unikraft.
Summary of objectives
- Port Musl
- Port / test threading support (including
clonesystem call) - Test and validate implementation
libc Test Library
Author: Răzvan Deconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated duration: 3 months
Priority: medium
Rationale for topic relevance
Port libc-test to test libc interfaces such as Musl and newlib.
Prerequisites / dependencies
Notes
- Florin Postolache is involved
ukstore (dynamic)
Author: Răzvan Deaconescu
Owner: Cezar Crăciunoiu
Tech lead: Simon Kuenzer
Estimated duration: 2 weeks
Priority: high
Rationale for topic relevance
Add dynamic entries in ukstore, the internal library for storing Unikraft data and passing it with getters / setters.
Notes
- PR available, waiting for review
Memory Ballooning
Author: Răzvan Deaconescu
Owner: Cezar Crăciunoiu
Tech lead: Simon Kuenzer
Estimated duration: 1 month
Priority: low
Rationale for topic relevance
Implement memory ballooning driver for Unikraft.
Summary of objectives
- Implement memory ballooning support in KVM
- Implement memory ballooning support in Xen
Notes
- PR available, waiting for review
Rust Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Vlad Bădoiu
Estimated duration: 2 months
Priority: high
Rationale for topic relevance
Add Rust support for external libraries / applications.
Applications written in Rust to be built on top of Unikraft.
Notes
- Dennis Kobert, Martin Koering are involved
containerd integration
Author: Alexander Jung
Owner: Alexander Jung
Tech lead: Alexander Jung
Estimated duration: 1 month
Priority: high
Rationale for topic relevance
Increasing Unikraft applicability, ease-of-use, and relevance.
Summary of objectives
runuetc.- Cloud Native integrations: e.g. plugin to k3s
Notes
- Iteration of shared libraries, and ability to pull them from environment
Memory Randomization
Author: Răzvan Deaconescu
Owner: Hugo Lefeuvre
Tech lead: Marc Rittinghaus
Estimated duration: 4 months
Priority: medium
Rationale for topic relevance
Memory randomization is an important security feature in modern applications / operating sytems.
It would be added to the Unikraft security features page.
Summary of objectives
- The Unikraft image (or the prebuilt Linux ELF application binary) would be loaded at different virtual memory addresses.
- Given sections in the Unikraft image could be loaded at different virtual memory addresses, independent among themselves.
- Randomize the page table location.
Prerequisites / dependencies
Notes
- The randomization of dynamic sections (heap, stack) is not part of the loader.
Unit Tests for Internal Libraries
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Library author
Estimated duration: 6 months
Priority: medium
Rationale for topic relevance
Unit testing ensure a good quality of the implementation.
Existence of unit tests allows regression testing: any new feature will be validated with existing unit tests.
Add unit tests (using uktest) for internal Unikraft libraries.
Code Conventions
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Marc Rittinghaus
Estimated Duration: 2 months
Priority: high
Rationale for topic relevance
Using code conventions ensures consistency and good practices in written code.
Otherwise, we get different styles and a general confusion from the contributor: "How should I write this code?"
Summary of objectives
- Agree on code conventions for the Unikraft project.
- Publish code conventions on Unikraft documentation website.
- Update implementation to follow code conventions.
Notes
- Initial ideas here.
ELF Loader
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated Duration: 2 months
Priority: high
Rationale for topic relevance
Increase application adoption by directly running unmodified Linux ELF binaries on top of Unikraft.
The ELF Loader will load a given ELF binary and pass control to it.
System calls will be passed to the shim layer.
Summary of objectives
- Use random memory loading.
- Support for dynamically-linked executables.
Notes
- Draft work from Simon Kuenzer, needs cleanup and update to latest Unikraft version
Unikraft Loader
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated Duration: 6 months
Priority: medium
Rationale for topic relevance
Have a loader as part of the unikernel image (or use a separate image).
The loader will then load the actual unikernel in memory.
This enables random placing of the unikernel and possible other features (load the unikernel for a specific architecture).
Summary of objectives
- Design loader separation from core unikernel image.
- Implement for different bootloaders and platforms.
- Add dynamic linking of Unikraft micro libraries.
- Use random memory loading.
Hyper-V Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Marc Rittingaus
Estimated Duration: 5 months
Priority: medium
Rationale for topic relevance
Add support for Hyper-V hypervisor.
Summary of objectives
- Add basic Hyper-V support.
- Add EFI support.
- Complete Hyper-V support.
Prerequisites / dependencies
Notes
- Implementation done by Paul Vlase
VMware Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Marc Rittingaus
Estimated Duration: 4 months
Priority: medium
Rationale for topic relevance
Add support for VMware hypervisor.
Prerequisites / dependencies
Notes
- Implementation done by Paul Ungureanu
Firecracker Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated Duration: 3 months
Priority: high
Rationale for topic relevance
Add support for Firecracker VMM.
Prerequisites / dependencies
Notes
- Work in progress by Andrei Topală
Baremetal Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Michalis Pappas
Estimated Duration: 5 months
Priority: low
Rationale for topic relevance
Build Unikraft as a baremetal image, i.e. running directly on hardware, without support from a hypervisor.
Prerequisites / dependencies
Notes
- Possible people to involve: Maria Sfîrăială
Multiple Bootloaders
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated Duration: 3 months
Priority: medium
Rationale for topic relevance
What happens if we boot from Multiboot, Multibootv2, uBoot.
If we build an image for QEMU/KVM we know it's Multiboot, and no need for other bootloader support.
This is tied to the plat rearch topic, due to the platform affecting the bootloader to be used.
Summary of objectives
- Add support for Multiboot2
- Add suport for uBoot
Prerequisites / dependencies
Others
- Jamboard discussion here
Platform Rearchitecting
Author: Simon Kuenzer
Owner: Michalis Pappas
Tech lead: Simon Kuenzer
Estimated Duration: 6 months
Priority: high
Rationale for topic relevance
Reorganization of architecture and platform code, better re-using of implementations across targets and clear definition where which implementation should be placed.
SMP-safe Unikraft Core
Author: Michalis Pappas
Owner: Michalis Pappas
Tech lead: Marc Rittingaus
Estimated Duration: 6 months
Priority: medium
Rationale for topic relevance
Make Unikraft core SMP-safe, i.e. Documentation of SMP-safe interfaces
Others
- Some work already being done by Sairaj (for GSoC)
SMP-safe Memory Allocation
Author: Michalis Pappas
Owner: Michalis Pappas
Tech lead: Hugo Lefeuvre
Estimated Duration: 4 months
Priority: medium-high
Rationale for topic relevance
Implement support for memory allocation that works correctly in an SMP-environment.
Notes
- Likely going to be lock-free.
- Maybe use a separate SMP-safe allocator; so we would have both non-SMP-safe and SMP-safe allocators.
- Of interest to OpenSynergy
POSIX mmap
Author: Michalis Pappas
Owner: Marc Rittinghaus
Tech lead: Marc Rittinghaus
Estimated duration: 4-8 weeks
Priority: high
Rationale for topic relevance
The current implementation of the mmap-group of functions is based on malloc. Unmapping does not work reliably with this. No support for paging code.
Summary of objectives
- Create data structure for efficient VA management (interval tree).
- Create uk-style API/library for VA management.
- Implement
posix-mmapbased on this API/library. - Keep the options to switch back to "poor man's version" of
mmap(such as when paging is not enabled).
Others
- Marc started implementing an initial version of
posix-mmap
W^X Support
Author: Marc Rittinhaus
Owner: Marc Rittinghaus
Tech lead: Michalis Pappas
Estimated duration: 1 week
Priority: medium
Rationale for topic relevance
Very important security feature.
Currently only supported on ARM (with paging) by setting up protections based on section information during boot.
General problem, section information incomplete.
Thus some protections are configured wrong -> crashes.
Summary of objectives
- Add W^X / DEP support using the NX / XD page bits on x86 / ARM.
- Generate static page table with correct protections as part of the build process (-> linker knows what sections exist and what protections are needed).
uknofault
Author: Răzvan Deaconescu
Owner: Marc Rittinghaus
Tech lead: Marc Rittinghaus
Estimated duration: 2-4 weeks
Priority: medium
Rationale for topic relevance
Internal library that returns a code instead of a page fault.
Useful for debugging.
GDB Stub
Author: Marc Rittinghaus
Owner: Marc Rittinghaus
Tech lead: Marc Rittinghaus
Estimated duration: 2 weeks (cleanup + upstream existing), +2 weeks (hw breakpoints, thread context support)
Priority: medium
Rationale for topic relevance
Enable GDB introspection of running Unikraft instance.
Provides the interface to list threads, memory allocations, open files in Unikraft etc.
Summary of objectives
- Add a GDB stub server in Unikraft, that a GDB client can connect to to debug the running unikernel instance.
- Add support for hardware breakpoints.
Prerequisites / dependencies
- Requires a second serial connection to Unikraft
- Cleanup work for ARM/x86
uknofault
Notes
- Current working version of ARM and x86
- Going to do a constant stream of changes over time.
Automated API Documentation
Author: Simon Kuenzer
Owner: Alexander Jung
Tech lead: Ștefan Jumărea
Estimated Duration: 4 months
Priority: medium-high
Rationale for topic relevance
Automatically generate API interface documentation from headers (e.g., doxystyle format).
To be published on https://unikraft.org/docs.
Summary of objectives
- Automate generation of API interface documentation.
- Complete and fix current interface documentation to the target annotation format.
- Include interface properties (for example indicating SMP-safety, thread-safety, reentrant-safety, isr-safety).
Prerequisites / dependencies
Core Library READMEs
Author: Alexander Jung
Owner: Alexander Jung
Tech lead: Ștefan Jumărea
Estimated Duration: 6 months
Priority: medium-high
Rationale for topic relevance
Introduce the relevant README.md file to each corresponding library.
Kernel Log Exporting
Author: Simon Kuenzer
Owner: Răzvan Deaconescu
Tech lead: Marc Rittinghaus
Estimated Duration: 4 months
Priority: medium
Rationale for topic relevance
Integration in monitoring/debugging systems of kernel logging via a remote console
Summary of objectives
- Output kernel messages to different outputs:
- log buffer (like dmesg)
- Syslog client
- Shell/SSH
Others
- Draft work from Alexandra Pîrvulescu
Unikraft Packaging
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Alexander Jung
Estimated Duration: 4 months
Priority: medium
Rationale for topic relevance
Deliver Unikraft and support filesystem / disk as unified image.
The image will be passed to the VMM.
Summary of objectives
- Add support in build system.
- Build sample images for supported applications.
- KraftKit target flavour.
Prerequisites / dependencies
Notes
- Jamboard discussion here
RISC-V Support
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Michalis Pappas
Estimated Duration: 1 month
Priority: medium
Rationale for topic relevance
Add support for RISC-V architecture.
Summary of objectives
- Add SMP support.
- Do code restructuring during/after platform rearchitecting.
- Add any other features that may be currently missing from the RISC-V port and are present in other architectures.
Prerequisites / dependencies
Notes
- Draft PR from Eduard Vintilă, requires review
- Core implementation already done and working with the latest (0.10) release. Needs reviewing, more thorough testing and (very probably) some refactoring.
Driver Shim Layer
Author: Răzvan Deaconescu
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated Duration: 4 months
Priority: low
Rationale for topic relevance
Implement software layer to port drivers.
Summary of objectives
- Provide driver shim layer as specialized library.
- Port sample drivers from FreeRTOS
Prerequisites / dependencies
Notes
- Draft work from Andreea Dumitrache
Signal Reimplementation
Author: Simon Kuenzer
Owner: Simon Kuenzer
Tech lead: Simon Kuenzer
Estimated Duration: 4 months
Priority: high
Rationale for topic relevance
Support handling and delivery of signals.
Summary of objectives
- Rewrite singals implementation within posix-process (currently broken)
- Signal delivery withinstruction pointer injection to a thread's context?
- Support signal handler stack switches, maybe some scheduling API extensions are needed
- Map platform requests to signals to the application (e.g., shutdown request as
SIGQUIT)
ISR-Safe Code
Author: Simon Kuenzer
Owner: Răzvan Deaconescu
Tech lead: Simon Kuenzer
Estimated Duration: 3 months
Priority: high
Rationale for topic relevance
We compile Unikraft with all compiler and CPU optimizations enabled. However, due to missing context saving of extended CPU units (vector, floating point) on interrupt/trap handlers, we need to make somehow sure that those functions are not using such registers because otherwise the original program flow might corrupt.
isrlib was introduced with a subset of nolibc functions that are compiled to be safe to be used in an interrupt service routine (ISR-safe).
Summary of objectives
- Enforce ISR-guarantee: An ISR-safe function should never call a non-ISR-safe function: Linker/compile tricks (e.g., compile isr functions into own section and forbid linking them with other non-isr sections (opposite direction is okay, actually)) or static analysis?
- Revisit compiler attributes: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes (
targetis worth a look). Maybe theisrvariant inMakefile.ukis not needed anymore - Make sure all interrupt handler paths are covered with ISR-safe property (drivers, trap handlers, …)
Notes
- Possible people: Adina, CristiV
Unikraft System Shutdown
Author: Simon Kuenzer
Owner: Simon Kuenzer
Tech lead: Simon Kuenzer
Estimated Duration: 1-2 week
Priority: high
Rationale for topic relevance
Enables clean unmounting of filesystems and flushing of disk block caches.
Summary of objectives
- Extend
uk_inittabwith corresponding termination function field. - Add shutdown handling to
lib/ukboot(call in reverse priority order).
