Project Description
This project aims to build a unikernel that has a sole purpose: run WebAssembly applications.
Unikernels offer a limited attack surface and theoretically can provide better performance compared to running the same application on top of a regular operating system. However, running applications on top of unikernels is not an easy tasks. Some might just work out of the box, others will require quite some efforts to be ported.
WebAssembly is a binary application format. A developer write their application using their favorite programming language, then compile it using the WebAssembly target. This produces a Wasm module, that can be run on top of a WebAssembly runtime. The runtime abstracts the underlying operating system and architecture, making the Wasm module capable of running everywhere. The WebAssembly runtime is also in charge of exposing a series of capabilities that can be leveraged by the WebAssembly guest. These capabilities could be system-related (like interacting with the filesystem, this is what WASI does) or could be functionalities provided by a specific platform (like accessing Key/Value stores, implementing http endpoints,... this is what platforms like Spin or Spiderlightning offer).
Why should we have a unikernel that runs WebAssembly:
- To improve security. Each WebAssembly runtime executes the WebAssembly code inside of a dedicated sandbox. This isolates the Wasm workloads from each other and from the host. However this is all done in software. By using a unikernel, we will be running the application on a host (the unikernel) that as a limited attack surface, plus it will be placed inside of a traditional VM that offers better isolation capabilities.
- To go fast. We could just place a regular WebAssembly runtime inside of a VM and call it a day (like running that inside of kata for example). However, having a super limited use case, I think we can build a really optimized system (à la firecraker)
Why I think this has higher chances of adoption compared to traditional "wanna run everything" unikernels:
- WebAssembly modules have clear boundaries. The set of capabilities offered is set by the platform (Spin, Spiderlightning) is limited. That reduces the amount of scenarios the unikernel must support.
- A better developer experience. A developer will build an application targeting a certain platform (Spin, Spiderlightning). This will produce a Wasm module that can be run, unchanged, by a regular WebAssembly runtime, including this unikernel. Both the regular WebAssembly runtime and the unikernel will implement the same set of capabilities. The WebAssembly guest won't even notice where its being ran.
Why am I doing this
I've always been fascinated by unikernels and I'm deeply into WebAssembly. I think there's a purpose for the two things to play together, as described above.
State of the project
I've a running POC. The unikernel is based on rusty-hermit, a unikernel written in Rust.
I've a unikernel application that is capable of running the unmodified WebAssembly module produced by the Spiderlightning key-value demo.
The unikernel is running inside of qemu, using kvm.
Goal for this Hackweek
Main goal - run WebAssembly
The main goal is be able to run the http server demo from Spiderlightning. I don't care about being able to run WASI modules, right now I just want to target some of the interfaces offered by Spiderlightning.
I don't need external help to achieve this goal.
Virtualization goals - HELP NEEDED
As an additional goal, I would like to replace the usage of qemu with something that is custom built.
We need a stripped down hypervisor that:
- Offers a network stack based on virtio - this is what hermit supports
- [Optional] offers a virtio disk backed by virtiofs - that's the only type of disk supported by hermit unikernel
We could leverage the Rust VMM libraries (the ones used by firecraker and crosvm) to build it, use cloud-hypervisor or other things you have in mind. It would be great to have all of that written in Rust, because it would allow me to reuse other Wasm/OCI-related things I'm already using inside of other projects I maintain/contribute to.
First step
Have a cli program that works in this way:
console
run
This would setup the network stack and run the unikernel image provided by the cli.
In this case we don't care about the unikernel being run. It could be the "hello world" example from hermit or it could be the wasm unikernel I'm building. In the latter case, the unikernel image would also bundle inside of itself the actual WebAssembly module.
Second step
Have a cli program that works in this way:
console
run
The binary will now bundle the wasm unikernel application, hence it's no longer required to specify that on the cli. Instead, on the cli the user will point us to the WebAssembly module to run.
The module will somehow be injected into the VM and consumed by the unikernel. How to do that, I have some ideas, but you're the virtualization expert, I rely on you to help me with that 
.
This makes the unikernel image generic, because there's no need to bundle the actual WebAssembly module to execute inside of it.
Resources
I've still to upload the POC on GitHub. In the meantime these are the Virtualization related links:
- Intro to hermit unikernel
- A hypervisor built by the hermit people: this is not meant to be used in production
- hermit wiki: it has useful resources, especially this one
- Bootloader to be used with qemu
- VMM reference implementation
- cloud-hypervisor
Looking for hackers with the skills:
This project is part of:
Hack Week 22
Activity
Comments
-
almost 2 years ago by flavio_castelli | Reply
Project update
I started writing a series of blog post about this project. You can find the first one here.
I got a POC working, I managed to achieve the "main" goal, but I didn't have time/help to accomplish the secondary virtualization goals.
You can find the working prototype here
Similar Projects
SUSE KVM Best Practices by roseswe
Description
SUSE Best Practices around KVM, especially for SAP workloads. Early Google presentation already made from various customer projects and SUSE sources.
Goals
Complete presentation we can reuse in SUSE Consulting projects
Resources
KVM (virt-manager) images
SUSE/SAP/KVM Best Practices
- https://documentation.suse.com/en-us/sles/15-SP6/single-html/SLES-virtualization/
- SAP Note 1522993 - "Linux: SAP on SUSE KVM - Kernel-based Virtual Machine" && 2284516 - SAP HANA virtualized on SUSE Linux Enterprise hypervisors https://me.sap.com/notes/2284516
- SUSECon24: [TUTORIAL-1253] Virtualizing SAP workloads with SUSE KVM || https://youtu.be/PTkpRVpX2PM
- SUSE Best Practices for SAP HANA on KVM - https://documentation.suse.com/sbp/sap-15/html/SBP-SLES4SAP-HANAonKVM-SLES15SP4/index.html
Extending KubeVirtBMC's capability by adding Redfish support by zchang
Description
In Hack Week 23, we delivered a project called KubeBMC (renamed to KubeVirtBMC now), which brings the good old-fashioned IPMI ways to manage virtual machines running on KubeVirt-powered clusters. This opens the possibility of integrating existing bare-metal provisioning solutions like Tinkerbell with virtualized environments. We even received an inquiry about transferring the project to the KubeVirt organization. So, a proposal was filed, which was accepted by the KubeVirt community, and the project was renamed after that. We have many tasks on our to-do list. Some of them are administrative tasks; some are feature-related. One of the most requested features is Redfish support.
Goals
Extend the capability of KubeVirtBMC by adding Redfish support. Currently, the virtbmc component only exposes IPMI endpoints. We need to implement another simulator to expose Redfish endpoints, as we did with the IPMI module. We aim at a basic set of functionalities:
- Power management
- Boot device selection
- Virtual media mount (this one is not so basic )
Resources
Contribute to terraform-provider-libvirt by pinvernizzi
Description
The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.
It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.
If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.
Goals
- Get more familiar with Terraform provider development and libvirt bindings in Go
- Solve some issues and/or implement some features
- Get in touch with the community around the project
Resources
- CONTRIBUTING readme
- Go libvirt library in use by the project
- Terraform plugin development
- "Good first issue" list
Harvester Packer Plugin by mrohrich
Description
Hashicorp Packer is an automation tool that allows automatic customized VM image builds - assuming the user has a virtualization tool at their disposal. To make use of Harvester as such a virtualization tool a plugin for Packer needs to be written. With this plugin users could make use of their Harvester cluster to build customized VM images, something they likely want to do if they have a Harvester cluster.
Goals
Write a Packer plugin bridging the gap between Harvester and Packer. Users should be able to create customized VM images using Packer and Harvester with no need to utilize another virtualization platform.
Resources
Hashicorp documentation for building custom plugins for Packer https://developer.hashicorp.com/packer/docs/plugins/creation/custom-builders
Source repository of the Harvester Packer plugin https://github.com/m-ildefons/harvester-packer-plugin
Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino
Description
A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.
The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.
On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).
I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.
Goals
- Learn about Rust and micro-controllers (ESP32-C3)
- Learn about mobile applications (Android and Kotlin)
Resources
Kanidm: A safe and modern IDM system by firstyear
Kanidm is an IDM system written in Rust for modern systems authentication. The github repo has a detailed "getting started" on the readme.
In addition Kanidm has spawn a number of adjacent projects in the Rust ecosystem such as LDAP, Kerberos, Webauthn, and cryptography libraries.
In this hack week, we'll be working on Quokca, a certificate authority that supports PKCS11/TPM storage of keys, issuance of PIV certificates, and ACME without the feature gatekeeping implemented by other CA's like smallstep.
For anyone who wants to participate in Kanidm, we have documentation and developer guides which can help.
I'm happy to help and share more, so please get in touch!
SMB3 Server written entirely in Rust by dmulder
Description
Given the number of bugs frequently discovered in the Samba code caused by memory issues, it makes sense to re-write the smbd service purely in Rust code. Meanwhile, it would be wise to abandon backwards compatibility here with insecure protocol versions, and simply implement the SMB3 spec.
Goals
Get a simple server up and running and get it merged into upstream Samba (which now has Rust build support).
Resources
Hacking on sched_ext by flonnegren
Description
Sched_ext upstream has some interesting issues open for grabs:
Goals
Send patches to sched_ext upstream
Also set up perfetto to trace some of the example schedulers.
Resources
https://github.com/sched-ext/scx
Implement a CLI tool for Trento - trentoctl by nkopliku
Description
Implement a trentoctl CLI for interacting with a trento installation
Goals
- learn rust
- implement an initial
trentoctltool to enhance trento automation - have fun
Resources
trento rust. TUIs listed on this other hackweek project Hack on rich terminal user interfaces