New Directions in Operating Systems
Notes from the New Directions in Operating Systems 1 day conference at the Shoreditch Village Hall in London.
Rump kernels and {why,how} we got here
Writing drivers and filesystems is hard. Want to reuse this existing code, continuing to benefits from updates. A rump kernel runs on a hypervisor. A normal OS kernel with most of the code removed. Does not provide threads, scheduler, exec, VM. Can therefore run anywhere and integrates with anything. Some glue code connects to hypervisor. Application can add libc, etc, if desired. The syscall interface contains much useful logic (e.g. path resolution), so want to keep that too.
Was able to compile to JavaScript and debug driver using FireBug. Fetched a web-page in the Linux kernel. Also runs on Xen (Mini-OS) and bare metal.
http://rumpkernel.org/ (BSD license)
Where are they useful?
- e.g. in embedded systems: reduces complexity
Genode -- OS security by design
Laptop boots to GENODE desktop environment. Aims:
- Reduce TCB (Linux has a very large attack surface, lots of code running with high privilege).
- Accountability and utilisation. Linux tries to provide an illusion of unlimited resources, with hacks like the OOM killer.
- Usable security. e.g. SE-Linux is unusable.
A GENODE system is structured as a tree, with parents owning their children. Parents provide resources to their children from their own resources and control what the children can do. Each application only needs to trust those components it depends on (e.g. its ancestors and services it uses).
Combined with virtualisations, can run e.g. Linux and BSD as processes. Also takes components from many places: Linux TCP stack, Rump kernel filesystems, etc, each running as a GENODE process.
Security is based on object capabilities. e.g. a child can tell its parent that it provides a service (e.g. the GUI) and other children can retrieve them. For example, xterm asks for access to the GUI. It’s parent, the user session, tags the request with the application name and passes it to its parent (init), which forwards it to the GUI. Once the capability is granted, the application can use it directly without going via its parents.
Processes can trade resources. For example, a client can make a request on a server and pass the server the resources needed for the request.
VirtualBox has been ported (shows it booting Windows). Not optimised yet, but was able to play a video under it (slightly jerky).
Using a modified libc, can run a Unix environment without needing a virtualised kernel. Uses Vi to edit the GENODE background, showing integration with the rest of the system.
Runs a web browser (Qt app). The File Open dialog shows only a few files - the browser can't access anything else. Browser can run GENODE processes as (isolated) plugins. Uses a nested GENODE GUI to run a 3D demo. The plugin is also isolated from the browser - the browser can't get key presses from it (not sure how this works).
Current focus is making it usable as a dev system, adding a capability GUI.
Eating own dog food
- noux (gcc, vim, bash coreutils)
- wireless networking
Capability-based UI
seL4 as base platform
ARM virtualization
package management
Q: How to revoke capabilities?
A: Destroy subsystem or destroy cap referent object.
New ideas about old OS security
Robert Watson, Cambridge University, FreeBSD
1990s: MAC and DAC. Orange book. Auditing. Slow, poor usability.
computer security in 2014
- embedded
- ubiquitous
- many computers per person rather than many users per computer
- security still neglected
- software liability still disclaimed
- lots of malware
Lots of access control models. Hard for OS vendors to decide what to implement. => Linux LSM, FreeBSD MAC, etc. LSM not very composable, but MAC is. If policies disagree, it uses the most restrictive one.
Filtering system calls is not a good approach, due to concurrency. Instead every kernel component talks to the MAC framework. Attach labels to many kernel objects. They are useful for many different security frameworks.
MAC originally controlled access by users, but on modern devices it’s applications that are the key subjects.
Debugging security is hard. Need good tracing. DTrace useful here.
Capsicum. Applications get compromised. Want to contain the attacker. Object capabilities for FreeBSD (extends POSIX by removing ambient authority). File descriptors become capability. Now a production feature in FreeBSD 10. Linux patches have been posted to linux-kernel. Linux seccomp required 11,300 lines of code, compared to 100 on Capsicum (doing what?).
Libraries can use sandboxing even when their application doesn’t.
Compartmentalization is Neat!
- but different ways to break things up
- has overhead
- hardware does this badly
- so, put capability support into the architecture!
- now, userspace sandboxing with little os intervention
- BERI/CHERI
- can we do fine-grained cpu-supported compartments and not touch kernel?
- How does tagged memory interact with virtual-memory systems?
- How should syscalls work? Sould be blox them?
- How do signals work?
CHERI downloadable now!
Conclusion
- Blurring boundaries to support application needs
- FreeBSD OS book (second edition)
- Saltzer and Schroeder
CHERI: Extending processors with better support for security. Open Source. Can be run on FPGA at home.
Managing configuration for future operating systems
Any input to infrastructure is configuration
Configuration management is about managing those inputs over time
History
Emerging Patterns
- immutable infrastructure
- infra APIs
- Autonomous systems
- Simpler hosts
Future infrastructure as code
History
50s research, 60s 480 series, 1991 MIL-HDBK-61 (conf mgmt guidance),
1998 ANSI-EIA-649?
Identification
Control
Status accounting
Verification and audit
Cfmg verifies that the system is identified and documented in detail and performs as intended
Infrastructure as code
Ruby puppet SSH config example
Immutable Infrastructure
- Build once, run many times
- Amazon Machine Images
- E2e automation to avoid the golden image problem (heavyweight build
requirements but no tracing)
- AMI build, audit, and trace cycle is faster, fundamental change
Containers
- Docker is the UI
- LXC was painful
- Usability matters
- We have the primitives for immutable infrastructure but toolchains
are coming up
How immutable are your Docker containers?
- Nothing. You must impose it.
Infrastructure with APIs
- Cloud providers
- OSv machine APIs
- Network and storage, too (not just compute)
- Not just *nix, windows, too
- I love PowerShell.
Configuration at a distance
- No physical access.
- No remote access.
- Not user-like. Programmatic.
Increasingly managing higer-level systems
- Not individual machines
- Servers are cattle not pets (fields and farms)
- Autoscaling groups (AWS)
- Mesos is a system which does this aggregation
- An operating system for a data center
- Kubernetes
- An ocean of user containers
- Scheduled and dynamically packed into nodes
Simpler hosts
- Combinatorial package explosion
- Management of this package configuration is hard
- Project Atomic addresses this
- OSTree "git for operating system binaries"
- atomic config example
- CoreOS
- For container operating system (etcd, initd)
- "firmware for running containers" ~ John Vincent lusis.org
Moving configuration from host to network
- etcd, consul, zookeeper
Future infrastructure as code
- From
- host centric
- localized
- executable for integration
- To
- Cluster centric
- Distributed
- HTTP for integration
Going from Puppet to etcd
- puppet is dsl for describing infrastructure
- provides a graph abstraction
- where similar interfaces exist, provides abstractions
- e.g. key value store
- garethr/key_value_config
Going from etcd to Puppet
- e.g. writing to disk
Software installation done
More interesting to control installed software
- start a docker container
- run app on mesos
- set up security groups on AWS
- digitalOcean
I want a pony
- Managing an autoscaling CoreOS/Atomic cluster in AWS
- with etcd/consul
- immutable instances
- with the network in VPC/Weave
- with docker container arranged by Kubernetes
- All from Puppet DSL
Conclusions
- Future here but not evenly distributed
- These tools look like the future
- Manage not just provision
- In Search of Certainty
Exploring a new way to manage systems with ostree and Atomic project
Michael Scherer, Red Hat
Ostree: read-only system in /usr (with symlinks to /var for mutable stuff). To upgrade, you must reboot. Can also reboot to old version. "Git for filesystem" (can branch, but not diff).
Want to protect base system from containers for OpenShift. Also, protect containers form each other. Uses SE-Linux for this (svirt).
Example: setting up a static web service, plus wiki and cache. Will put everything in a different container. Web designer used Fedora 20, so want to use the same. Want to isolate mediawiki from the network, except for the cache service. Using S3 storage for mediawiki. Want to make sure that updates are tracked, not just hacks on the production server. Everything is described in a JSON file (not shown).
Tribblix: adventures with illumos
Peter Tribble, Tribblix
Good features: ZFS, DTrace, Zones, compatibility.
Some cruft in the code base, bits not open sourced, things that need to be brought up-to-date.
Various distros: OpenIndiana, OmniOS (servers), SmartOS, Delphix (storage), etc.
But didn't like them. Wanted to understand how as OS really works. => Tribblix.
Focus on being retro, lightweight. Uses zones for app deployment.
Problems: not enough time or people. Fragmentation (work only being done at the distro level), SPARC port (about 3 users), cgo (C Go bindings) not working.
Rumprun for Rump Kernels: Instant Unikernels for POSIX applications
Martin Lucina, Lucina & Associates
Rump kernel plus:
- threads, scheduling, MM, locking, events (from hypervisor)
- libc
- build system to make existing code work without changes
- deployment: rumprun (configure network, mount FSs, platform-specific launching)
e.g. "rumprun xen ...". Runs as PV Xen guest using Mini-OS. Bare metal in progress.
Demo: compiles to 20MB hello world (debug build).
Demo: builds the same project once for Unix and once for Xen. Passes parameters for network and to map host files to guest NS.
Lots of changes to Mini-OS; needs upstreaming.
An introduction to userland networking
Currently, no standards in this area. Reasons to do it include: speed, keeping complex code out of the kernel, using user-space libraries, binary libraries from venors, debugging.
gettimeofday slows things down. So, push the timestamp into the packet metadata and pass it through the stack.
zero copy: share memory between kernel and user. DPDK is stable. PF_RING has nice API. Linux only / GPL. Also, Intel only. Netmap (FreeBSD; patches exist for Linux).
Hard to play around with transport layer if you have to recompile the kernel every time.
Example: switch positions of TCP port and sequence number headers. If both endpoints are modified they will still work, but to monitoring systems on the path it will be difficult to track them (looks like the port keeps increasing).
Weave: Myths of the New OS
Weave: software defined network, for networking containers. Focus is ease of use.
Docker has changed things: now a container is what you ship.
New myths (like Sun's old networking myths):
- App lifecycle is indep of OS. An app is a single-purpose OS.
- Distributed systems need new tools and skills. We can now actually go back to older tools. e.g. DNS, DHCP.
- Apps must be rewritten.
- Platforms are better at building your app.
- You need an all-inclusive system. People want pluggability.
- Dev/test tools and different from production tools.
- Coordination is a platform concern. Transactions should be handled by the app.
Network Stack in Userspace
Hajime Tazaki, University of Tokyo
It takes a long time to get a new network feature (e.g. a TCP option) deployed and widely used. In the filesystem world, FUSE makes it easy to test new features easily, even though performance isn't great.
Options:
- Containers: but, the network stack is still shared with the host
- Library OS
NUSE is a library OS version of a normal network stack. Patch to the kernel tree adds new arch "arch/sim". Hijacks application's system calls to redirect to NUSE so that existing apps don't need to be changed.
Possible uses for NUSE: developing new protocols, process-level network virtualisation. Currently, very few applications work unmodified (ping etc).
Jitsu: Just-in-Time Summoning of Unikernels
In distributed systems, complexity is the killer. We need to get rid of all these layers. We all depend on infrastructure that suffers security breaks again and again. Let’s get rid of POSIX and just keep network protocols as the standards.
Example: the slide stack is being server from a little ARM box (attached to the laptop by a network cable).
Although Mirage often runs of Xen, Mirage is more general than that. e.g. there is a JavaScript backend. You can start by building against Unix with Linux sockets, then remove this and use direct stacks.
Mirage aims to be contained, compact and efficient. And type-safe.
Each Xen guest has a flat memory layout and uses a single core. We trust all the code running in the unikernel, relying on type-safety, and try to protect against external threats.
Some common unikernels (DNS server, web server, etc) are around half a MB (smaller with dead-code elimination). Unikernels boot fast enough that they can be used like processes. Small enough to store the binaries in Git. Example: git pull to update web-site. Can git bisect to track down problems. Can detect a commit to a Git repository fixing a security bug and recompile within seconds.
Mirage defines abstract module types for devices, network flows, etc. There are about 80 libraries implementing these protocols.
OCaml is a good choice because of its module system. Like C++ templates but with more type safety.
http://nymote.org is a project building various services using Mirage.
Example: OCaml video decoder compiled to JavaScript. The Mirage JavaScript port replaces the entire HTTP library with JavaScript requests.
Example: TLS echo service running on ARM board, all implemented in OCaml.
CentOS Linux: A Continuously integrating platform
CentOS has thousands of extra tests, performed on every build. Build by ops people, not developers.
It's the MySQL developers' responsibility to check their code, but CentOS's responsibility to make sure it links against the right versions of its libraries.
They have a custom build system called Reimzul. A system of triggers will e.g. run the tests for MySQL when openssl changes. Can automatically find code that changed and map it to tests that failed.
Also test external uses of CentOS. e.g. check that WordPress and Drupal still work after a CentOS change.
Also sanity checks: e.g. new version number is higher than previous.
128 physical machines, 768 cores.
How to program computers (kos)
Geo Carncross, Telemetry
Kos is a tiny OS written in K. Very fast by avoiding bloat. Terse syntax. KDB database written in K. Violates what is generally considered best practices in programming - food for thought.
DIOS, a distributed operating system for your data centre
Malte Schwarzkopf, University of Cambridge
Too many abstractions are bad for scalability, scheduling, data locality, data-flow tracking security, optimisations. Get away from POSIX - make an API for datacentres. Distributed OS.
DIOS adds 11 syscalls to POSIX. UUIDs for global object names. Kernel provides objects, but provides additional data about them. e.g. where stored. Can be used for optimisations. DIOS runs in the Linux kernel, but is portable enough that it could be ported to BSD.
Example: loads dios kernel module and uses it for map reduce (word counting). Could run across machines, but for demo all running on one laptop.
Status: alpha
Currently no libc; must write to syscall API. Working on a Rust API.
seL4 microkernel: Leave nothing to chance: building high-assurance software systems
Bernard Blackham
Aim: eliminate all bugs through formal methods. Decompose system into small pieces and verify them. This requires strong isolation.
seL4 is a high performance ARM+x86 microkernel. ~10 KLOC. Also suitable for real-time systems.
Kernel is written in C and compiled with gcc. Every C function has an abstract specification: will terminate, will not crash, will not modify other memory, etc.
- Proof spec provides integrity, confidentiality and availability.
- Proof C implements spec.
- Proof machine code implements the C. Could use a certified C compiler, but actually they use a solver to prove the binary is correct (requires human help).
Can generate driver code automatically from specs (done for disk controllers, network cards, etc). Should be correct by construction (currently, no proof that generated drivers match spec).
Cost: about $200-$400 per line of code. 25 person years for the kernel.
Isolation should now let us scale up.
Code, specs and proofs are on github.
Trying to make an OS popular: a cautionary tale
Experience doing marketing for Ubuntu (to 2012). Ubuntu's founding goal was originally to fix bug #1 - the dominance of Windows. Wanted to centralise everything around Ubuntu/launchpad and bring open source to the masses.
Plan was Canonical would work closely with manufacturers.
Problems:
- OSS communities suspicious as launchpad not open source.
- Git beat bzr.
- PS makers scared of MS.
- Intel had nothing to gain.
- Public indifferent. Hard to interest people outside the core enthusiasts.
- Ubuntu diversification confused people.
Lessons:
- Focus on a clear message.
- Beware of big companies setting the direction. e.g. Ubuntu-for-TV is not a community driven idea.
- Don't rely on other people to finish your project when it's not their key focus.
What should have been done differently?
Ubuntu cloud and server could have been split out.
Leave a comment