80 lines
3.9 KiB
Text
80 lines
3.9 KiB
Text
---
|
|
title: Robust Open Bare-metal Ubiquitous Resilient
|
|
author: someone
|
|
---
|
|
|
|
TODO: vermutlich ist es marketingmaessig klug, folgende features besser zu verkaufen:
|
|
- targeted hypervisors: KVM, ... on amd64 and arm64; Xen on am64 and arm32
|
|
- compiles to JavaScript (for single-language web applications)
|
|
- high-level memory-safe language allows for quick turnaround cycles during development and feature addition
|
|
- visualisation / comparison of the trusted code base
|
|
- decent performance
|
|
- fast boot time
|
|
- several libraries already deployed by others (Docker)
|
|
- 'scalable cloud-ready' (cap'n proto, prometheus, ...)
|
|
- small footprint (MB of memory -> lots of per server)
|
|
- could spawn a VM for each user
|
|
- energy efficient (https://sites.google.com/view/energy-efficiency-languages/)
|
|
|
|
Computers on the Internet get compromised,
|
|
- to access data on the computer (databases, passwords, user accounts) or block
|
|
access to it (Ransomware),
|
|
- to participate in DoS of other services (e.g. the Mirai botnet on SmartTVs)
|
|
and manipulate opininon (chatbots).
|
|
|
|
The software stack is often missing critical security updates, most embedded
|
|
devices (home router, SmartTV, etc.) have no secure update channel, they need a
|
|
secure system from the start.
|
|
|
|
Recent security solutions focus on containing compromised software by using
|
|
virtualisation technology and containers. But the root cause remains: running
|
|
old systems that are insecure.
|
|
|
|
Instead of trying to fix these decades-old operating systems, which were
|
|
designed as multi-user time sharing systems of the past, we build small services
|
|
from scratch with security in mind, directly on the virtualization layer. In
|
|
our operating system, each service is a separate virtual machine with only the
|
|
required code (usually no need for process- and user management, or a file
|
|
system), and no copy of a multi-purpose operating system kernel.
|
|
|
|
This makes our systems much smaller. The binary size of an HTTP server with TLS
|
|
support in our system is around 4% compared to one in a conventional operating
|
|
system, making the attack surface much smaller.
|
|
|
|
Additionally, we use a safe programming language: a statically and strongly
|
|
typed functional programming language with automated memory management. This
|
|
reduces the attack vectors: temporal and spatial memory corruption are no
|
|
concern anymore. The declarative programming style makes it possible to
|
|
formally verify the correctness of the entire virtual machine with a theorem
|
|
prover.
|
|
|
|
One of our single purpose operating systems boots within milliseconds, and has a
|
|
tiny memory footprint. For client-side features that run in a webbrowser, we
|
|
compile to JavaScript from the same codebase, to ensure consistency. The strong
|
|
and static type system helps to detect errors early, and enables rapid
|
|
prototyping. For production use the prototype code can be further optimized for
|
|
performance.
|
|
|
|
## Conclusion
|
|
|
|
MirageOS started as a research project, and has matured to a full suite for
|
|
building secure operating systems, with libraries that work well in production
|
|
and cover a variety of application needs. MirageOS is a game changer for secure
|
|
network services, since the attack surface is minimised to 1% of the size of
|
|
other contemporary operating systems. In addition, common attack vectors are
|
|
avoided by the usage of a programming language with memory safety. A unikernel
|
|
boots within tens of milliseconds, and services can be spawned on demand. When a
|
|
request (e.g. a DNS request) for a unikernel comes in, the kernel boots up,
|
|
handles the request, and is destroyed after an inactivity period. Only the
|
|
necessary services need to run, and they can be short-lived to minimize state in
|
|
the system.
|
|
|
|
The choice of a high-level programming language also allows for rapid
|
|
prototyping, new features can be developed quickly. In contrast to scripting
|
|
languages, the code does not need to be re-implemented for production use (but
|
|
nevertheless can be fine-tuned for performance).
|
|
|
|
|
|
WHY YOU NEED THIS!
|
|
WHAT ERRORS WE CAN AVOID
|
|
HOW WE CAN HELP
|