---
title: "Community Meeting, August 25, 2022"
tags: unikraft, community, roadmap
datetime: 2022-08-25T10:00:00+02:00
location: Online, Discord (https://bit.ly/UnikraftDiscord), the `#monkey-business` voice channel
teams:
- community
participants:
- TODO
---

[toc]

## :dart: Agenda

- OSS Roadmap (2022-2023)

## Proposals

:::info
_copy-paste this and fill contents:_

### Topic: [template]

**Author**: Firstname Lastname
**Owner**: TODO
**Tech lead**: TODO
**Estimated duration**: TODO

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- [Please fill in here]
:::

---

### Topic: Kubernetes (`containerd` integration)

**Author**: Alexander Jung
**Owner**: Alex
**Tech lead**: Alex
**Estimated duration**: 6 months

**Rationale for topic relevance**

Increasing Unikraft applicability, ease-of-use, and relevance.

**Summary of objectives**

- `runu` etc.
- Cloud Native integrations: e.g.
- plugin to [k3s](https://k3s.io/);
-

**Prerequisites / dependencies**

- Iteration of shared libraries, and ability to pull them from environment;

---

### Topic: Memory Randomization (ASLR)

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Tech lead**: Marc
**Estimated duration**: 4 months

**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](https://unikraft.org/docs/features/security/).

**Summary of objectives**

The Unikraft image 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.

The randomization of dynamic sections (heap, stack) is not related to the Unikraft Loader.

We also need to randomize the page table location.

**Prerequisites / dependencies**

- Unikraft Loader

---

### Topic: Unit Tests for Internal Libraries

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Tech lead**: TODO
**Estimated duration**: 6 months

**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.

**Summary of objectives**

Add unit tests (using [uktest](https://unikraft.org/docs/develop/writing-tests/)) for **all** [internal Uniraft libraries](https://github.com/unikraft/unikraft/tree/staging/lib).

**Prerequisites / dependencies**

N/A

---

### Topic: Code Conventions (Internal)

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Tech lead**: TODO
**Estimated Duration**: 4 months

**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](https://unikraft.org/docs/).
Update implementation to follow code conventions.

**Prerequisites / dependencies**

- N/A

**Notes**

Initial ideas [here](https://docs.google.com/document/d/1_iRkdBjQtnqOj798ZNr23OQTWQcXPdpDsnfBikm6Pcg/edit).

---

### Topic: Unikernel Loader

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Tech lead**: TODO
**Estimated Duration**: 6 months

**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**

- Memory Randomization (enables), e.g., initial page table that is handed over to Unikraft platform boot code
- Dynamically linking Unikraft micro libraries
- Maybe fat Unikernel images (multiple platform libs and one selected depending on target)

**Prerequisites / dependencies**

- [Please fill in here]

---

### Topic: HyperV Support

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: 5 months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- Platform Rearchitecting

---

### Topic: VMware Support

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: 4 months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- Platform Rearchitecting

---

### Topic: Firecracker Support

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: 2 months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- Platform Rearchitecting

---

### Topic: Baremetal

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: 5 months
**Priority**: Low

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- [Please fill in here]

---

### Topic: Multiple Bootloaders

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: TODO months

**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**

- [Please fill in here]

**Prerequisites / dependencies**

- [Please fill in here]

---

### Topic: Platform Rearchitecting

**Author**: Simon Kuenzer
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

Reorganization of architecture and platform code, better re-using of implementations across targets and clear defintion where which implementation should be placed.

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- [Please fill in here]

---

### Topic: SMP-safe Unikraft core

**Author**: Michalis Pappas
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- Difficult to split in tasks.
- Documentation of SMP-safe interfaces

**Prerequisites / dependencies**

- [Please fill in here]
- Some work already being done by Sairaj (for GSoC)

---

### Topic: SMP-safe memory allocation

**Author**: Michalis Pappas
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- 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

**Prerequisites / dependencies**

- [Please fill in here]

**Others**

- Of interest to OpenSynergy

---

### Topic: POSIX mmap / mprotect

**Topic Author**: Michalis Pappas
**Owner**: Marc Rittinghaus
**Estimated duration**: 4 - 8 weeks

**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-mmap` based on this API/library
- Keep the options to switch back to "poor man's version" of `mmap` (such as when paging is not enabled)

**Prerequisites / dependencies**

- [Please fill in here]

**Others**

- Marc started implementing an initial version of `posix-mmap`

---

### Topic: W^X Support

**Topic Author**: Marc Rittinhaus
**Owner(s)**: Marc Rittinghaus
**Estimated duration**: 1 week

**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)

**Prerequisites / dependencies**

- N/A (paging support already enabled)

---

### Topic: GDB stub

**Author**: Marc Rittinghaus
**Owner**: Marc Rittinghaus
**Estimated duration**: 2 weeks (cleanup + upstream existing), +2 weeks (hw breakpoints, thread context support)

**Rationale for topic relevance**

[Please fill in here]

**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.

- Current working version of ARM and x86

**Prerequisites / dependencies**

- Requires a second serial connection to Unikraft
- Cleanup work for ARM/x86
- `uknofault` library (return code instead of a page fault, last cleanup necessary for PR)

---

### Topic: Automated API Documentation (doxygen or similar)

**Author**: Simon Kuenzer
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

Automatically generate API interface documentation from headers (e.g., doxystyle format). To be published on docs.unikraft.org.

**Summary of objectives**

- Automated 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**

- Code Conventions

---

### Topic: Kernel Log Exporting

**Author**: Simon Kuenzer
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

Integration in monitoring/debugging systems

**Summary of objectives**

- Output kernel messages to different outputs
- log buffer (like dmesg)
- Syslog client
- Shell/SSH

**Prerequisites / dependencies**

- [Please fill in here]

**Others**

- Draft work from Alexandra Pîrvulescu

### Topic: Unikraft Packing

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- Bootloader
- KraftKit target flavour

**Prerequisites / dependencies**

- [Please fill in here]

### Topic: RISC-V Support

**Author**: Răzvan Deaconescu
**Owner**: Eduard Vintilă
**Estimated Duration**: 1 month

**Rationale for topic relevance**

Running Unikraft on 64 bit RISC-V based platforms targeting KVM. Core implementation already done and working with the latest (0.10) release. Needs reviewing, more thorough testing and (very probably) some refactoring.

**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**

- Platform Rearchitecting

### Topic: Driver Shim Layer

**Author**: Răzvan Deaconescu
**Owner**: TODO
**Estimated Duration**: TODO months

**Rationale for topic relevance**

[Please fill in here]

**Summary of objectives**

- [Please fill in here]

**Prerequisites / dependencies**

- Baremetal

---

### Topic: posix-process: Signal Reimplementation (alias uksignal) [upcoming]

**Author**: Simon Kuenzer

**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`)

---

### Topic: ISR-Safe Code

**Author**: Simon Kuenzer

**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 (`target` is worth a look). Maybe the `isr` variant in `Makefile.uk` is not needed anymore
- Make sure all interrupt handler paths are covered with ISR-safe property (drivers, trap handlers, ...)

---

### Topic: Unikraft System Shutdown

**Author** Simon Kuenzer

**Rationale for topic relevance**
Enables clean unmounting of filesystems and flushing of disk block caches

**Summary of objectives**
- Extend `uk_inittab` with corresponding termination function field
- Add shutdown handling to `lib/ukboot` (call in reverse priority order)

---
## :closed_book: Discussions

### Musl Support

SK: Musl work is going well.

Dragoș did work on the Musl + newlib.

Simon working on Unikraft core PRs.

All PRs should go to the `staging-muslpreview` branch.

Instead of using newlib, we will be using Musl.

### Community Organization

RD: Topics take too long.
Musl has been in the works for 3 years.
I think it's good to have a roadmap and deadlines, to give people a push and focus to get things done.

RD: The model where there is a task owner / driver is a good one.
A topic would have a task owner that would then assemble a team to work on that topic.
Similar to SMP on ARM (Michalis lead, Rene, Răzvan on team), Musl (Simon lead, Robert, Dragoș, Florin on team), kraftkit (Alex lead, Ștefan, Gabi, Cezar, AndreiA on team).

## :wrench: TODOs and Decisions

Everyone: Add estimated durations for each topic.

RD: Draft version of roadmap

gantt
    section Section
    A task           :a1, 2014-01-01, 30d
    Another task     :after a1  , 20d

    section Another
    Task in sec      :2014-01-12  , 12d
    anther task      : 24d