homepage-data/Home

81 lines
3.9 KiB
Text
Raw Normal View History

2017-09-10 22:25:32 +00:00
---
2017-09-16 17:04:53 +00:00
title: Robust Open Bare-metal Ubiquitous Resilient
2017-09-10 22:25:32 +00:00
author: someone
---
2017-09-16 17:04:53 +00:00
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/)
2017-09-16 16:52:05 +00:00
Computers on the Internet get compromised,
2017-09-16 17:04:53 +00:00
- 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).
2017-09-16 16:52:05 +00:00
2017-09-16 17:04:53 +00:00
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.
2017-09-16 16:52:05 +00:00
2017-09-16 17:04:53 +00:00
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.
2017-09-16 16:52:05 +00:00
2017-09-16 17:04:53 +00:00
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.
2017-09-16 16:52:05 +00:00
2017-09-16 17:04:53 +00:00
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.
2017-09-16 16:52:05 +00:00
2017-09-16 17:04:53 +00:00
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.
2017-09-16 16:52:05 +00:00
2017-09-16 17:04:53 +00:00
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.
2017-09-16 18:06:47 +00:00
## 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