Unikraft v0.14.0 (Prometheus) is out and comes packed with tons of fixes and new features that improve the overall Unikraft ecosystem.
In this blog post, we describe some of the new features available in Unikraft. For a full breakdown, please check out the changelog.
With the release of Unikraft 0.14, the build system officially supports a macOS-based development environment. Unikernel images can be developed, compiled, and tested directly on macOS. Both types of Macs are supported: you can do this on a Mac with an Intel processor or with an Apple silicon. Only the following packages are expected to be installed on the system via Homebrew:
brew install gnu-sed make m4 gawk grep wget qemu socat git# ...for compiling x86_64 unikernelsbrew install x86_64-elf-binutils x86_64-elf-gcc# ...for compiling aarch-64 unikernelsbrew install aarch64-elf-binutils aarch64-elf-gcc
Behind the scenes, Unikraft uses the Python-based Kconfiglib to configure Unikraft on a Mac. The build system automatically chooses the Linux-equivalent command-line tools on Mac to perform a successful build.
Within a terminal session, Unikraft can be cloned in the same way as on Linux:
git clone https://github.com/unikraft/unikraft.gitcd unikraft
Configuration and compilation can be invoked with
# Configure (select an architecture and platform)gmake menuconfig# Buildgmake
Also on Mac,
qemu-guest can support in running built Unikernels with QEMU:
support/scripts/qemu-guest -t arm64v -k build/unikraft_qemu-arm64
Unikraft bootable through
AArch64by relocating the kernel, fetching the command-line, initial RAM disk, Devicetree blob and setting up the memory region descriptors as well as bridging the gap between the components initialized by UEFI and those supported by Unikraft
The arm64 Linux boot protocol defines the layout of a Linux image, the kernel parameters, and the system configuration expected by the boot environment.
0.14 introduces support for the
arm64 Linux boot protocol, which allows booting Unikraft into any environments that expects an
arm64 linux image, such as boot loaders or VMMs like Firecracker.
This release introduces the ability to boot
arm64 builds of Unikraft on Firecracker.
Firecracker is an ultra-light VMM that allows creating and running microVMs, combining the security and isolation properties of VMs with the flexibility and ease of use of containers.
uk_store API provides micro-libraries with the ability to register getters and setters for various properties.
uk_store with the ability for microlibraries to dynamically create and destroy
This paves the road for features like per-device statics, dynamic entries in virtual file systems like
sysfs, and more.
This release introduces a so called
SUBBUILD feature to the build system.
It adds the ability to place generated files (e.g., pre-processed, compiled units) in a subdirectory of a library build directory.
For this purpose, the build system looks for a file-scoped variable with the suffix
Such a variable contains a path that is created below the library build directory.
The feature is especially useful for generating headers with a pre-processor, like AWK or M4.
# Create `myheader.h` under `build/libmylib/include/uk/`LIBMYLIB_SRCS-y += $(LIBMYLIB_BASE)/myheader.m4>.hLIBMYLIB_MYHEADER_SUBBUILD += include/uk# Register the include folder of the library with the generated headerCINCLUDES-$(CONFIG_LIBMYLIB) += -I$(LIBMYLIB_BUILD)/include
TREE BUILD is an alternative library registration mode for the build system which automatically handles subdirectory paths for build products.
The work adds
addlib_tree_s as library registration functions.
For each library in tree mode, the build system places build products in a subdirectory structure that mirrors the directory structure of the corresponding source file.
This is a very handy tool to simplify the porting of libraries whose source files span multiple directories.
Based on the SUBBUILD build feature, this release introduces library identifiers with
The new library generates at compile-time unique IDs for each library.
Such a ID starts from
0 and increases linearly so that they can be used for table lookups with
The library provides helpers to map identifiers to names and vice versa.
lib/ukstore are first users of this library and adopted accordingly.
A clear separation between runtime and compile-time resolution of library identifiers is done so that libraries can potentially be built off-tree and shipped in binary form.
Each library's own identifier (
uk_libid_self()) is stored in a constant variable that is resolved during link-time.
The owner of the identifier variable is
uklibid, so that the identifier is external to a binary library.
Unikraft is now position independent, can be built as a static
PIE and self relocate on both
CONFIG_OPTIMIZE_PIEto build Unikraft as a static
CONFIG_LIBUKRELOCautomatically selected by
CONFIG_OPTIMIZE_PIEand implements Unikraft's custom relocation system:
ur_mov) as well as numerical values declarations GNU Assembler directives (
ur_data) and a way to create relocatable static Page Table entries (
It is now possible to dynamically mount additional volumes via the introduction of a new command-line argument
vfs.fstab that is meant to contain a list of whitespace separated strings with the following format:
The core will parse the provided strings as volume information and attempt to mount them accordingly, if
CONFIG_LIBVFSCORE_FSTAB is provided.
vsyscall (virtual system call) is the first and oldest mechanism used to accelerate system calls.
Due to security concerns, it has been deprecated, and
vDSO (virtual dynamic shared object) serves as its successor.
However, in the context of unikernels, kernel isolation is not a concern, allowing us to utilize both of them.
app-elfloader now supports both of these features.
If you don't have the source code of your application but desire the performance of Unikraft,
app-elfloader can load unmodified ELF files.
However, there will be some performance overhead compared to a native build, while the two newly introduced features can help mitigate this difference.
vDSO is available for both dynamically linked applications and statically linked ones, to accelerate certain commonly used time-related system calls (
As a result, some server programs can experience significant performance improvements.
If your application is dynamically linked, it can further utilize
vsyscall to avoid costly binary syscalls (since
vsyscall has been deprecated in the latest version of libc, we provide patched dynamic runtime libraries for
The Unikraft applications now contain
README.md files with very easy to use instructions for running the applications, both using
kraftkit and the
Make-based build system.
We take advantage of the
defconfig build rule, that can generate a full
.config file starting from a given minimal configuration.
The minimal configurations (for multiple supported platforms and architectures) are already provided in the application repositories, and can be used as such:
UK_DEFCONFIG=$(pwd)/.config.helloworld_qemu-x86_64 make defconfig
After the configuration file is generated, the application can be build using
make and run using the instructions from the
As part of the Unikraft Summer of Code final hackathon, we also focused on the binary compatibility side, porting a lot of new applications and adding them in the
Among the new ported applications are
In order to have a one to one version match between the binary compatibility and native application,
app-redis was also updated to version
Preliminary steps in using GitHub actions as a continuous integration have been undertaken. These allow the building and running of tests at PR submissions, as a complement and future replacement of the current Concourse-based system.
In conjunction to this, a new application
catalog repository will store application files and serve as the sole go-to place for grabbing applications that can be built and run on top of Unikraft.
We are also excited to announce the first native ports of third-party Python packages:
We update the Go support to version 1.18 an fully integrated
lib-go with Musl.
Go applications are now fully functional on top of Unikraft for
In the near future Go support will be updated for
We now provide
Clang support for compiling for
x86_64 and cross-compiling for
This is exciting news as it opens the door for cool compiler enforced security features and better integration for platforms such as Darwin (unikraft#685).
Use the following command to compile with Clang, both on
x86_64 and on
AArch64 (depending on the configuration):
$ make CC=clang
We're excited to announce an official coding conventions guideline! This comprehensive document outlines that one should have in mind when submitting contributions to out codebase, whether it's a first-time contributor or a well-known veteran.
By introducing these conventions, we want to ensure consistent and clean code across all our repositories and make maintenance more efficient. The document includes naming conventions, indentation guidelines, commenting practices, and many more. Happy coding!
You can now influence the Unikraft build process via a set of environment variables.
UK_ASFLAGS: explicit Unikraft-specific additions to the assembler flags (the
ASFLAGSvariable is ignored)
UK_CFLAGS: explicit Unikraft-specific additions to the C compiler flags (the
CFLAGSvariable is ignored)
UK_CXXFLAGS: explicit Unikraft-specific additions to the C++ compiler flags (the
CXXFLAGSvariable is ignored)
UK_GOCFLAGS: explicit Unikraft-specific additions to the GO compiler flags (the
GOCFLAGSvariable is ignored)
UK_LDFLAGS: explicit Unikraft-specific additions to the linker flags (the
LDFLAGSvariable is ignored)
UK_LDEPS: explicit, space-separated link-time file dependencies (changes to these files will trigger relinking on subsequent builds)
This info is also shown on
UK_LDEPS flags are of special interest, as they allow injecting externally built object files into the Unikraft image.
This approach will be further integrated into KraftKit via
kraftld is a drop-in replacement for a gcc-flavored linker, allowing the transparent linking of object files into Unikraft images.
A follow-up blog post will describe this approach and its design in more detail and will show how this is used to bring Rust support to Unikraft.
We want to keep track of entities using Unikraft and foster collaboration.
unikraft core repository there is now an
ADOPTERS.md file storing Unikraft users and, ideally, contributors (companies, universities, institutions) that benefit from using Unikraft as part of their commercial, research or teaching activities.
If you are an entity using Unikraft, follow the submission guidelines and submit a pull request to update the
And expect full support from the Unikraft community in assisting your work and integrating contribution in the Unikraft project.
The third edition of Unikraft Summer of Code took place this July, had about 45 participants, and consisted in 6 sessions and a final hackathon. The sessions covered topics like building and running unikernels, debugging, porting applications, etc. The final hackathon was a full day event, and the participants had their chance to apply the things they've learned and to contribute to Unikraft. It took place both in person, at University POLITEHNICA of Bucharest, and online, on Discord. A lot of work was done on application porting and binary compatibility, with more than 35 issues and pull requests opened.
We plan to keep organising the Unikraft Summer of Code in the following years, and make people eager to learn more about low-level topics, operating systems, unikernels, and, most importantly, the open source world.
As we want to speed up the unikernels ascent, we decided to organize a discussion group involving all the people that are interested and bring their contribution into this field.
We decided to name our group the "Unikernel Alliance". This is a community formed from existing unikernel and libOS communities, aimed at popularizing and promoting unikernel-like solutions in research, industry and in technical communities.
We organize monthly meetings, featuring technical talks from the group members. Until now, we have organized three meetings. You can find the recordings and slides here.
Together with our friends from RWTH Aachen, we organized the first edition of Unikernels in the Wild, an event centered on knowledge sharing in the Unikernels area. Răzvan Deaconescu and Răzvan Vîrtan participated from our side, having presentations and offering support during the practical workshops.
The day started with a few presentations about the general view and latest updates in RustyHermit. Then, we moved on with two presentations about binary compatibility and memory allocation in Unikraft. Also, our collaborators from Nubificus (remember the Athens Hackathon?) gave a presentation about their work on getting unikernels into the DevOps mainstream. The day ended with two hands-on sessions for Unikraft and RustyHermit.
This event has been a great chance for getting together people from the Unikernels community and we hope it will become a tradition!
If you are using Unikraft, consider adding your affiliation in our
We use this file to keep a track of entities that use Unikraft for their commercial and / or research work.
We are proud to be one of the Google Summer of Code organizations for the second year in a row!
During these last months, our 5 students have started their work and already achieved some amazing intermediary results! You can find more about the progress of our mentees in the following blog posts:
Stay tuned for news regarding the final status of their projects!
Feel free to ask questions, report issues, and meet new people.