News: 1610622187

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Another Rust-y OS: Theseus joins Redox in pursuit of safer, more resilient systems

(2021/01/14)


Rust, a modern system programming language focused on performance, safety and concurrency, seems an ideal choice for creating a new operating system, and several such projects already exist. Now there is a new one, Theseus, described by creator Kevin Boos as "an Experiment in Operating System Structure and State Management."

The key thinking behind Theseus is to avoid what Boos and three other contributors from Rice and Yale universities call "state spill".

[1]

In a [2]paper presented at the USENIX symposium on operating systems design and implementation last November, the researchers defined this as when "one software component harboring changed states as a result of handling an interaction from another component, such that their future correctness depends on said states."

[3]

Editing code for Theseus: the developers recommend Visual Studio Code

[4]

This is the norm in modern systems, they said, and gave as an example that if an Android system service fails, the "entire userspace framework" crashes, affecting all applications even those not using the failed service.

State spill is a barrier to reliability, they argued, which impacts everything from firmware in tiny pacemakers to networks in data centres. In order to discover "to what extent state spill can be avoided in OS code", the researchers decided to write a new OS from scratch, choosing Rust because it has an ownership model.

Ownership, [5]described by the Rust docs as "Rust's central feature", key to how the language achieves memory safety, enforces three rules:

Each value in Rust has a variable that's called its owner

There can only be one owner at a time

When the owner goes out of scope, the value will be dropped

Avoiding state spill required rethinking OS structure, the researchers said, in particular how the OS is modularised. Theseus OS has many tiny components, called cells, each with clear bounds. Cells are based on Rust crates (project containers).

The bigger innovation, though, is what they call "intralingual OS design" by which they mean using programming language mechanisms to implement the OS. The idea is to "shift semantic errors from runtime failures into compile-time errors."

This means that Theseus is more deeply tied to Rust than other Rust-based operating systems.

[6]

Cells in Theseus are Rust crates and can be swapped out for fixing problems or updating the OS

State management is handled using principles based on client-server models. Clients own their state and servers use stateless communication "which dictates that everything necessary for a given request to be handled should be included in that request."

This is familiar from REST web models. Theseus therefore avoids things like handles, pointers to resources owned by the operating system, in favour of owning their resources directly.

Resilience in Theseus uses a technique called cell swapping, where new cells replace existing ones and take on their dependencies. An old cell is not actually dropped until it is no longer referred to by any other cell.

Fault recovery involves replacing corrupt cells with new ones. This, the researchers claimed, "allows [Theseus] to tolerate faults in the lowest system layers in the face of multiple failed subsystems."

Similar mechanisms enable live updates. In a test of fault recovery, the researchers injected 800,000 faults and achieved a 69 per cent successful recovery rate.

How is performance?

"We do not claim that Theseus generally outperforms existing OSes like Linux... but our results do not indicate significant performance drawbacks," the researchers said, based on tests like [7]LMBench .

Despite its experimental architecture, there are limitations. Unsafe code is "an unfortunate necessity in a low-level kernel environment," the researchers said, because of the need to interact with hardware. Another limitation is that components must be implemented in safe Rust.

Other "safe or managed" languages could be supported, but unsafe languages would need hardware or software based isolation. The designers are also compromising principles in some areas, such as the file system.

"A fully spill-free FS would break existing POSIX interfaces by granting sole ownership of a file to the client currently accessing it, meaning that the file would appear to be absent until the client releases it."

That sounds inconvenient. The "current tradeoff" is to support legacy file system standards and accept state spill for this case.

Currently Theseus is [8]on GitHub and comprises 38,000 lines of Rust code and 900 lines of assembly. The operating system can be built on Linux, Windows using WSL (Windows Subsystem for Linux), macOS, or in a Docker container. It can be run in the QEMU emulator.

The team loves Visual Studio Code for development, and said it has "excellent cross-platform support for Rust. Other options are available, but we don't recommend them."

Another prominent Rust-based OS is [9]Redox OS , currently at version 0.6. The last major update was in December, and included a complete rewrite of the kernel memory manager, many updated and new components including a greatly improved relibc library (used by most user applications), and a new package format called pkgar.

[10]

Redox OS is another prominent Rust-based OS but with a more familiar, Unix-like design

Why bother with Theseus when we have Redox?

The answer is that the two projects have little in common, other than the use of Rust and that they are new operating systems. Redox supports Unix-like syscalls, and has an architecture "largely inspired by MINIX," [11]according to its docs.

Redox will be more familiar to developers. Note, though, that Redox does aim to be resilient with isolated components, resistance against one failed component crashing other components, and restricted communication between components. Redox, its designers claimed, is "for users that want minimal issues with their computer systems." That sounds like most of us.

Another Rust-based operating systems is [12]Tock , designed for embedded systems. There are others, but most are not very active.

The question raised by Theseus is whether a radically different new operating system can have sufficient advantages to overcome the huge difficulties of establishing it in a world so heavily invested in existing ones like Linux (and Linux-based Android), macOS, and Windows.

[13]

Google has a good chance with [14]Fuchsia , perhaps. A Rust-based option is attractive, though, and projects like this one and Redox OS are worth watching. ®

Get our [15]Tech Resources



[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x250&tile=2&c=2YAB4rbP8tUfoAnQzhtL7YQAAABU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[2] https://www.usenix.org/conference/osdi20/presentation/boos

[3] https://regmedia.co.uk/2021/01/13/theseus.jpg

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x250%7C300x252%7C300x600&tile=3&c=33YAB4rbP8tUfoAnQzhtL7YQAAABU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dtop%26test%3D0

[5] https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

[6] https://regmedia.co.uk/2021/01/13/cellswapping.jpg

[7] http://www.bitmover.com/lmbench/

[8] https://github.com/theseus-os/Theseus

[9] https://www.redox-os.org/

[10] https://regmedia.co.uk/2021/01/13/redox.jpg

[11] https://doc.redox-os.org/book/ch01-06-how-redox-compares.html

[12] https://www.tockos.org/

[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x100%7C300x250%7C300x251&tile=4&c=44YAB4rbP8tUfoAnQzhtL7YQAAABU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[14] https://fuchsia.dev/

[15] https://whitepapers.theregister.com/

Security is a word

Version 1.0

Writing a secure operating system with a secure language means that No Such Agency and others will be writing code in Rust to help out. Will we be seeing secure access in the future? While this may fix some security problems, it guarantees nothing - trusting an operating system just because it's written in Rust is the same as assuming that your code is fine and bug free because there were no compiler errors.

Yes, I'd be very happy to see a completely secure operating system but when it's released, how long before it needs to be patched?

Re: Security is a word

overunder

I'm not sure what you're talking about (you really lost me), but as for "security" and while I really like Rust, the article title is VERY naive...

"This one is not just written in Rust – its design is based on Rust features "

Yep, and when there was an OS first written in C, people hailed that it had to use particular features to be competitive... wait for it... WAIT FOR ITt.......... _POINTERS*_!! . And here we go, doing it all over again. The ASM people must be having deja vu (or an ironic laugh).

Rust is great, I really do like it. However, it will not be better than what we already have in C or C++ as we're 40 years in with those and Rust just isn't that "next level" (or at all) to be considered for a migration.

Re: Security is a word

DrXym

Rust is safe, not secure. The two things are orthogonal although there is some overlap.

For example, many C/C++ exploits are due to things like buffer over/underflows. Rust makes it very hard to write code that is vulnerable to that form of attack - at worst you'll get a panic rather than an exploit. Likewise for other exploitable things like null pointer exceptions, heap corruption etc.

However Rust isn't going to help if the function was supposed to verify a certificate's trust chain but didn't.

So I would consider it an extremely useful foundation for any secure software or operating system, but it does not mean in and of itself that code will be secure.

Success

A Non e-mouse

To determine if an operating system is a success depends on what its aims are and how easy it is to port the relevant programs to it.

If it's to run databases, Postgres & Mysql are going to be important. Or if it's a web server, Apache/NGnix plus plugins is important.

etc.

"There are others, but most are not very active"

Pascal Monett

Which sounds to me just like most forks of existing projects on GitHub.

There are a lot of people who have an idea and are willing to try to start a project.

There are a lot less people who are willing and capable of bringing that project to term, not to speak of maintaining it in the long run.

The fact that a new OS might have trouble rubbing shoulders with the entrenched versions is not an excuse. When Torvalds unleashed Linux on the world, he had no idea he was the guy who was going to allow the Internet to function, most IoT crap to exist and be the father of dozens of similar distros.

He just did it, and thank God he did.

You make a new OS that actually works and does what is says on the tin, and you make something that will find its way organically into the IT infrastructure of the world.

Take the market into account and you might as well not start.

Re: "There are others, but most are not very active"

Janne Smith

Linux got a boost in interest at a key moment because of a crisis in the BSD Unix world. Just as the first BSD projects were getting into their stride, AT&T sued BSDi alleging there was some of their copyrighted code in BSDi's products. This put a chill on the FreeBSD project since they were relying on the same BSD codebase, and quite a few developers switched to Linux citing its genesis as a ground up implementation of a Unix kernel.

Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982