As far as I can tell, Rust OS projects generally use gratuitous amounts of unsafe code and are not substantially different than if they were written in C. I could just be looking in the wrong places. Are there any that take advantage of Rust's type system to provide real guarantees?
"In the previous post we switched from assembly to Rust, a systems programming language that provides great safety. But so far we are using unsafe features like raw pointers whenever we want to print to screen. In this post we will create a Rust module that provides a safe and easy-to-use interface for the VGA text buffer."
That may just be the impression given by tutorials, which spend most of their time dealing with the hardware. In a real OS, you'd wrap that up in safe interfaces and then the core of things like scheduling, file systems, etc. could be in a safe layer on top of the unsafe drivers.
IMO, the answers to those questions are "no" and "yes" respectively. Redox in particular seems like it has way more unsafe code than it actually has to (though it seems to have gotten a bit better very recently).
There's a period of writing only all the usual stuff that you've done before, then slowly discovering what kinds of abstractions you can put over it, and what kinds of stuff needs to remain super-low.
There are times that you have to do "unsafe" things when interacting directly with hardware. That's not to say one shouldn't attempt to limit the use of "unsafe" to use cases that absolutely require it.
I'd like to see someone re-implement the QNX real-time microkernel in Rust. That would be useful. We need a QNX-like OS for embedded devices. Linux is really the wrong tool for the job. Too much extra stuff which allows attacks.
I agree. That or at least MINIX 3's core components as there's already source available. Plus, that would likely get extended by all the people building servers and stuff. Be two versions like with Linux.
seL4 is quite good, but their approach to message passing has a problem. Messages are limited to a few bytes passed in registers. Anything bigger has to be done through shared memory between processes. This is great for the kernel; it never has to do a long operation like a big copy, so there's an upper bound on the time for each kernel operation. But with shared memory, one process may be able to mess up another. The usual library for L4 shared memory puts multiple "chunks" into one shared memory area, with an allocator. "A shared memory area can have multiple chunks."[1] Messing with the chunk structure or the wrong chunk from one process may adversely affect another one. That's a bad kind of attack surface.
So, although the kernel is secure, server processes with higher privileges than their callers may not be. Since this is how processes talk to file systems and drivers, it's an obvious way to attack.
QNX copies data from one process space to another. This adds copying overhead, but it's usually not too bad, because 1) most messages are short, and 2) if you just created a message and sent it, it's in the cache. In practice, the big overhead item today is context switching.
Do you think anything could be done to mitigate or fix that? I've only recently started digging into seL4 so I don't know if this is an unavoidable problem (in terms of proving correctness) or if it even needs to be solved in-kernel.
I asked, both before QS sold it to RIM and after the deal, in both cases I didn't even get an answer (and I would have been in a position to put up a substantial chunk of money in order to get a dual license deal in place). Real pity, but maybe it will still happen.
QnX is one of the most elegant OSs out there and having a public domain or GPL'd version of it would be a great thing.
If anyone is considering working on an OS in Rust, they could perhaps consider writing a small hypervisor that could replace Xen, Nova and similar hypervisors.
This provides the same low-level challenges of writing a kernel, but it's far easier to get practically usable software than attempting to replace Linux and would actually be useful in practice.
At the moment, the only way to make a sandbox that has a chance of being perfectly secure (i.e. no security holes, ever) while still running all kinds of useful software is to use VMs to sandbox Linux/Windows kernels, and here the hypervisor is of course the weak point, and current usable hypervisors are written in C or C++.
This seems to be about using Rust for the kernel running inside the virtual machines, not for the hypervisor itself, which is what I was talking about.
I've read through what was here, and last night, actually built the first post's code. I really like the depth and style of this particular posts, it really hits a sweet spot.
I was looking for something similar in C. Most of the resources I found (eg : os dev-wiki) do not cover the implementation details in such depth. Can anyone give few pointers?
Well, Rust is a systems language, and so it should be a good fit for OS development. We're still working on bits of it, but it's a stated goal of the language, so testing that out is valuable.
> Novelty
Well, Rust is still a fairly young language, so there aren't a ton of people doing things with it yet, relatively speaking. And for OS dev, which is kind of a niche subject anyway (as much as I love it), there's naturally even less. So it's basically novel by definition.
> Well, Rust is a systems language, and so it should be a good fit for OS development. We're still working on bits of it, but it's a stated goal of the language, so testing that out is valuable.
My questions was not well formulated. Let me rephrase it: C is also a system language and there are plenty of OS libraries written in C. C++ could be seen as another system language. Even the syntax of Rust is similar to C/C++ according to Wikipedia article. So, what's the advantage of Rust over other systems language? Better support for autonomous systems? Reflective model? Do you have a paper? It is a research project? Do you plan to replace Linux or something like that?
(Safe) Rust provides some nice guarantees. It (should be) impossible to have use-after-free, buffer overruns, race conditions, etc. in 100% Safe Rust. A pure Rust OS could provide a safe interface to build safe programs.
While mostly a novelty, an OS capable of executing untrusted code risk-free could be a powerful tool indeed.
To prove to all C fanboys that believe it is the only language that ever existed for systems programming, that there are memory safe ways to do systems programming. And in the process advance the current state of OS safety.
https://github.com/redox-os/redox
It's pretty incredible how quickly it's come together, there's a reasonable looking GUI already!
Edit: The author also did an AMA on reddit: https://www.reddit.com/r/rust/comments/3mw67c/i_am_jackpot51...