- speaking now: @mindypreston (@yomimono on github)
- we released version 3.0 in February
- tl;dr: supports KVM via the solo5 project
- better errors
- better logs
- better interface
- https://github.com/mirage/mirage/releases/tag/v3.0.0
- solo5 is improving to target more things: bhyve, Hypervisor.Framework
LinuxKit: assemble a particular set of components in order to make a platform.
With known components, a question arises:
could you be using better components?
Our goal: allow operators to choose (and invent!) more secure, more specialized implementations of the components they need.
- run in a container as a single static binary.
- follow a common configuration convention based on bind mounts from the host.
- NOT intended to be portable to other Linux or OS distributions
- (We will support and encourage portable patchsets to be maintained by the community for other operating systems)
Within the context of LinuxKit, what conventions can we demand or enforce to try to hit "more secure"?
- the container has the minimal capabilities required to execute.
- after configuration is read, the service privilege separates itself to drop as much as possible.
- processes use KVM to supply extra hardware protection if available, via the Solo5 project.
- if KVM is not available, use seccomp-bpf to restrict the set of syscalls used.
- all untrusted network traffic must be handled in memory-safe languages.
- support automated fuzz testing so that tools like AFL can run regularly to detect bugs proactively.
- The SDK will initially support OCaml (via MirageOS)
- Next up: Rust
- Later: other languages via server-side WebAssembly
- Never: C or other memory-unsafe languages without sandboxing
- Very, very embryonic ;)
- Currently, we're working on proofs-of-concept to nail down the interface
- first: DHCP client
- next: ntpd, https?
- important
- if you need DHCP, you won't be able to network without it
- trusted
- needs to be able to set host configuration information
- complicated
- particularly risky because it often implements its own parsers
|=================| |================|
| priv | | calf |
|=================| |================|
| | | |
<-- eth0 ---> | BPF rules | <--- network IO ---> | type-safe |
| | (data path) | network stack |
| | | |
|-----------------| |----------------|
| | | |
<-- logs ----- | | <------- logs ------ | type-safe |
| | | protocol logic |
<-- metrics -- | | <----- metrics ----- | |
| | | |
|-----------------| |----------------|
| | | |
<-- audit --- | config store | <----- KV store ---> | config store |
diagnostic | daemon | (control path) | client |
| | | |
|_________________| |________________|
| |
<-- syscalls - | |
| |
| system handlers |
<-- config --- | |
files | |
|_________________|
- linuxkit/projects/miragesdk/examples/mirage-dhcp.yml
- dhcp container config in /containers/services
- config exposed in /var/run/dhcp-client
- logs in /var/log/dhcp-client.log
- calf drops off information, priv acts on it
- make it easy for developers to write new services
- make it easy for operators to introspect running services (and their interactions)
- small, constrained, specified services might sound familiar to you
- and there's a reason we wanted to start with OCaml
- well-architected libraries let us write small shims for the custom LinuxKit interaction
- benefit from the community and momentum of the existing MirageOS project
- we'll talk more later :D