Xous: Rust Semantics in your OS

Betrusted: Being Secure

That's no Blackberry, it's a chat client!

Sean Cross - https://xobs.io/ - @xobs

Betrusted: A Security Chip with I/O

Xous: A Betrusted OS

Betrusted Goals

<=4 MiB RAM
Safe language
Process Isolation

Microkernel
Auditable by one person

With Betrusted, we wanted to reduce the code footprint. This will allow us to run with less RAM -- ideally 4 MiB or less. We also wanted to have a full MMU, which is somewhat unusual in the embedded microcontroller space, where a more limited Memory Protection Unit is preferred. Whereas the Linux kernel is huge, not to mention all of the support libraries required to run a system, we would like the Betrusted system to be auditable by one person. Lowering the memory footprint helps in this regard, as the less RAM we have, the less code we must have. Additionally, we would like to have the operating system written in a safe systems language to protect us from common programming errors involving memory and concurrency. Even so, we would like to have full process isolation, so even if one process is compromised, attackers will have a harder time boring through the system to gain a more complete takeover. This allows us to have legacy software written in non-safe languages, in case we need to take third-party code such as font renderers from legacy systems. As a result, we would like Betrusted to run a Microkernel-style operating system, with "servers" that provide features such as the display, keyboard, and even basic task switching. These should all run in userspace with the bare minimum permissions required to get the job done.

Microkernels

FlexSC: Flexible System Call Scheduling with Exception-Less System Calls

Too Many Cooks

	if there is one primary contributor, the chances for a file to be buggy decreases significantly
Source: Microsoft Research

Felix' Rule of Thumb

The largest amount of security-related code that one person can reasonably audit is about 64 KiB of binary data

Principles of Software

Safety
Concurrency
Speed
Size

The Rust programming language promises the holy trifecta: Safety, Speed, Concurrency. Pick any three. If you're going to start over on a systems- level project, choose Rust. There will be a lot of wailing and gnashing of teeth to begin with, but the end result will be better. When we started Betrusted, we decided that it should primarily use Rust as the systems language. That way we can be sure that our code is sound. Additionally, Rust has the ability to produce efficient binaries, and the efficiency is only going to get better as time progresses. This eliminates non-Rust choices such as Linux or Minix.

Rust OS Landscape

Rust-based OS: Tock


Active Project RISC-V Port C and Rust Libs	No MMU Support No runtime spawn() Limited messaging

Tock is the most obvious choice, since it already has a RISC-V port and is supported by a well-documented ABI. Tock supports multiple tasks written in either Rust or C, which is a very nice feature. However, Tock does not support an MMU. It would be possible to adapt the MPU interface to work with an MMU, but a lot of design work has gone into Tock to make it work well with only the standard MPU that is present on most ARM chips. Using Tock would be asking it to do something that it's not designed for. Instead, it's better to pick the right tool for the job. Additionally, the Tock message passing infrastructure assumes only one server per process, which can limit flexibility.

Rust-based OS: Redox


Active Project Full Rust stdlib Full Userspace	x86_64 only Unix-like Desktop-focused

Redox is the other large Rust-based operating system, and is the most compelling. Redox is currently limited to x86-64 (with a plan to port it to AArch64), so we would need to port it ourselves to RISC-V. The biggest problem with Redox is its size: It's a full Desktop operating system, and supporting it on Betrusted would require us to spend a lot of time cutting it down to just the bare microkernel, at which point we can start to recreate everything ourselves. The kernel itself is such a small part of Betrusted. Besides, we would like the freedom to experiment, to randomize the syscall numbers and have keepout areas of the screen and add IMEs to the input, which would quickly introduce incompatibility with Redox. Finally, we would like to be able to use stable Rust for our applications, which we can almost do with Xous. We're just waiting for either the "alloc_error_handler" attribute to be stabilized (issue 66740), or defaulting handle_alloc_error to panic (issue 66741), which would give us everything we'd need to use alloc on stable Rust. In short, Tock is too small, and Redox is too big.

Rust-based OS: Tifflin

?
Active Project Rust stdlib Full Userspace	nightly only Mainly x86_64 ???

Other Alternatives and Inspirations

ChibiOS - Embedded RTOS
HelenOS - Everything is a message
Solaris - Doors
QNX - Traditional Microkernel

Microkernels isolate and make IPC cheap

Xous: System Design

Xous: Memory Model

Rust Borrow Checker
Message passing
Inter-process borrowing
Borrow types:
- Mutable ^ Immutable
- No Access | Read Only

Image CC-BY Tammy

Xous: Memory Model

Mutable Borrow
- draw()
Immutable Borrow
- Mapping font database
Move
- Encrypting a string

Xous: Interrupts

fn setup_int2() -> xous::Result {
    let gpio = xous::syscall::map_physical(
            Some(0xe0000000), None, 4096)?;

    xous::syscall::claim_interrupt(2, |_int_num, gpio| {
        unsafe {
          let val = gpio.read_volatile();
          gpio.write_volatile(val + 1);
        };
    }, gpio)
}

All in userspace

Interrupts block the whole system, and follow similar behavior to memory. That is, each interrupt can only be assigned to a single handler. This is an example of a server claiming interrupt 2, and this function will be called to handle that interrupt. It will be called in Supervisor mode with the process space of this server. During the interrupt handler, interrupts are disabled, and after it returns they will be re-enabled. You can't make any syscalls in this mode that don't have an "_i" suffix. This will form the basis of drivers running in userspace using safe code.

Xous: Missing Features

fork()
Filesystem
Scheduler
Threads
Locking primitives
Shared libraries

Xous has no fork(). Instead it will have spawn(). Xous has no scheduler. The scheduler will be implemented as a userspace program, which will request the Timer interrupt and call a kernel function to preempt the current process. It has no threads. However, there is enough information passed from the kernel to enable the userspace scheduler to implement threads. Similarly, it has no kernel-level locking primitives. Because memory can't be shared between processes, there is no need for inter-process locking. Within a process, threads are available with LLVM intrinsics such as cmpxchg. Shared libraries aren't available at the start, but may come later via shared immutable borrows from the linker server.

Xous: Everything in Userspace

Small Kernel
Message Passing
Protected Memory

Understandable by one human

Made by many

Betrusted: Being Secure

That's no Blackberry, it's a chat client!

Betrusted: A Security Chip with I/O

Xous: A Betrusted OS

Betrusted Goals

Microkernels

Too Many Cooks

Felix' Rule of Thumb

Principles of Software

Rust OS Landscape

Rust-based OS: Tock

Rust-based OS: Redox

Rust-based OS: Tifflin

Other Alternatives and Inspirations

Xous: System Design

Xous: Memory Model

Xous: Memory Model

Xous: Interrupts

Xous: Missing Features

Xous: Everything in Userspace

Developing Xous

Renode: C: The Good Parts