A sandboxed execution environment for unikernels
Clone or download
mato Merge pull request #309 from adamsteen/openbsd_fix
OpenBSD fixes for 'Enable printf-style parameter check for log() func…
Latest commit 0535461 Jan 22, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
bindings Merge pull request #309 from adamsteen/openbsd_fix Jan 22, 2019
docs spt: Add basic documentation Jan 21, 2019
include/solo5 "spt" (seccomp) target Jan 18, 2019
scripts Renaming: Sundry (solo5-run-virtio, solo5-mkimage) Sep 12, 2018
tenders spt: block: Check lseek() result, use 64-bit types Jan 21, 2019
tests "spt" (seccomp) target Jan 18, 2019
.gitignore "spt" (seccomp) target Jan 18, 2019
.travis.yml "spt" (seccomp) target Jan 18, 2019
AUTHORS Native Genode bindings Oct 16, 2018
CHANGES.md Update CHANGES for v0.4.1 Nov 8, 2018
GNUmakefile spt: OPAM integration Jan 18, 2019
LICENSE Renaming: Update license and copyright texts Sep 12, 2018
Makefile.common Stack smashing protection Dec 7, 2018
README.md spt: Add basic documentation Jan 21, 2019
build.sh CI: allow override of "sudo" Apr 24, 2018
configure.sh spt: Handle host toolchains without PIE support Jan 18, 2019
solo5-bindings-genode.opam spt: OPAM integration Jan 18, 2019
solo5-bindings-genode.pc.in Native Genode bindings Oct 16, 2018
solo5-bindings-hvt.opam spt: OPAM integration Jan 18, 2019
solo5-bindings-hvt.pc.in Renaming: OPAM packages Sep 13, 2018
solo5-bindings-muen.opam spt: OPAM integration Jan 18, 2019
solo5-bindings-muen.pc.in Renaming: OPAM packages Sep 13, 2018
solo5-bindings-spt.opam spt: OPAM integration Jan 18, 2019
solo5-bindings-spt.pc.in spt: OPAM integration Jan 18, 2019
solo5-bindings-virtio.opam spt: OPAM integration Jan 18, 2019
solo5-bindings-virtio.pc.in Renaming: OPAM packages Sep 13, 2018


            |      ___|
  __|  _ \  |  _ \ __ \
\__ \ (   | | (   |  ) |
____/\___/ _|\___/____/

About Solo5

Solo5 originally started as a project by Dan Williams at IBM Research to port MirageOS to run on the Linux/KVM hypervisor. Since then, it has grown into a more general sandboxed execution environment, suitable for running applications built using various unikernels (a.k.a. library operating systems), targeting different sandboxing technologies on diverse host operating systems and hypervisors.

Some of the unique features of Solo5:

  • a public ("guest-facing") API designed for ease of porting existing and future unikernel-native applications,
  • this aforementioned API facilitates the implementation of ("host-facing") bindings and tenders designed with isolation, a minimal attack surface and ease of porting to different sandboxing technologies or host systems in mind,
  • support for live and post-mortem debugging of unikernels,
  • fast "boot" times (comparable to loading a standard user process), suitable for "function as a service" use-cases.

Looking for the "ukvm monitor"? Since Solo5 0.4.0, our terminology has changed to better reflect the intended architecture and long-term goals of the project. What used to be referred to as a monitor is now referred to as a tender. As part of this change, the ukvm target and monitor have been renamed to hvt ("hardware virtualized tender") to reflect that they are no longer specific to the KVM hypervisor, and to allow for development of further tenders such as spt.

Getting started

As Solo5 is essentially a piece of "middleware" interfacing unikernel-style applications with their host systems, it is not an end-developer product as such.

To get started as a developer with Solo5, please refer primarily to the instructions provided by the unikernel project you intend to develop applications with:

That said, we provide the following documentation, not specific to any unikernel in particular:

Contributing and community

Solo5 is developed on GitHub and licensed under a liberal ISC license. We accept contributions via GitHub pull requests. When submitting a contribution, please add your details to the AUTHORS file, and if your contribution adds new source files copy the copyright header from an existing source file.

The coding style for the project is "as for the Linux kernel, but with 4 spaces instead of tabs". When in doubt, please follow style in existing source files.

We operate a mailing list for general Solo5 development discussion, at solo5@lists.h3q.com. To subscribe to the list, send an empty email to solo5-subscribe@lists.h3q.com. Archives are available at The Mail Archive.

If you are considering a substantial contribution to Solo5, would like to port a new unikernel to Solo5, or have general questions unrelated to a specific unikernel, please get in touch via the mailing list.