73 lines
3.8 KiB
Text
73 lines
3.8 KiB
Text
---
|
|
title: Robust Open Bare-metal Ubiquitous Resilient
|
|
author: someone
|
|
---
|
|
At robur, we build performant bespoke minimal operating systems for high-assurance services.
|
|
With our approach to systems development we provide the following advantages for you:
|
|
* systems based on the unikernel pioneer [MirageOS](https://mirage.io)
|
|
* secure implementation guarded against memory corruption, typelevel problems, leaky abstraction and unforseen state
|
|
* ready for the cloud, services run on all major hypervisors
|
|
* instant boot
|
|
* competitive performance comparable to C / C++
|
|
* can target embedded devices because of small size and the ability to compile to native code
|
|
* minimized state allows to reason about entire systems and their adherence to the specification
|
|
* extensive library ecosystem, yet minimal trusted code base at runtime
|
|
* rapid prototyping with a seamless path from prototype to production
|
|
|
|
Computers on the Internet get compromised mostly to gain or block access to data.
|
|
User data is being downloaded, leaked and sold, or ransomware blocks access to user data until a fee
|
|
is paid. Other common attacks target compute resources, to use them in denial of service
|
|
attacks or to manipulate opinion with chatbots.
|
|
|
|
Common software stacks often include legacy parts at runtime that provide unnecessary attack surface.
|
|
Critical security updates are rarely deployed on time, because they result in unforeseen behaviour. Also, lots of embedded
|
|
devices are missing a secure update channel.
|
|
|
|
======
|
|
Instead of trying to fix these decades-old operating systems, which were
|
|
designed based on demands at that time (e.g. time-multiplexed multi-user
|
|
computers), we build small services from scratch with security in mind. Each
|
|
service is run as a separate virtual machine on any hypervisor with only the
|
|
strictly necessary code.
|
|
|
|
This makes our virtual machines much smaller. The binary size of an HTTP server
|
|
with TLS support is around 4% compared to one using a conventional Linux
|
|
operating system, making the attack surface much smaller.
|
|
|
|
Additionally, we use a functional programming language with static
|
|
types and 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 unikernels boots within milliseconds, and has a
|
|
minimal 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
|