LWN: Comments on "Redox: a Rust-based microkernel"

Redox: a Rust-based microkernel

farnz — Thu, 14 Apr 2016 09:16:54 +0000

The other problem with URIs is that they are a universal (and hence unambiguous) identifier that needs no additional context to interpret correctly. Great for computers, but horrible for humans; we seem to universally prefer shorter context-dependent identifiers[0] - so, for example, "Mark" is a perfectly clear identifier for a single unique individual in context, and yet, depending on context, you could be referring to Mark Shuttleworth (plausible in an Ubuntu setting) through Mark Twain (plausible in a literary setting) through Mark the Evangelist (Christian church). A URI can't deal with that - the context has to form part of the URI so that it's a universal identifier.

In that respect, filesystem paths are better - they're not universal, and thus it is reasonable that ls can refer to (depending on context) ./ls, or /bin/ls, or ~/bin/admin-help/ls, or even /usr/bin/ls on your machine instead of mine. Further, we have tools (like search paths, current working directories, aliases, chroots, bind mounts, symbolic links etc) that allow you to define your own context for a given filesystem path.

[0] Think pronouns and other pro-forms in natural language - I can't find evidence of a natural language that doesn't have any pro-forms at all, nor can I find one where it's completely unacceptable to use an ambiguous identifier and rely on context to resolve it.

Redox: a Rust-based microkernel

nix — Tue, 12 Apr 2016 00:04:08 +0000

It seems like a really good idea, and then they go and make everything a URI. It's like they've never read Pike's 'The Hideous Name' or, if they did, didn't understand it. URIs are a *really bad choice* for a universal filesystem locator, with at least six irregularly separated components (some optional), each with completely different quoting rules: they're profoundly non-nestable without massive and ugly transformations, and generally horrific from top to bottom.

But, hey, it's all people know now :(

Redox: a Rust-based microkernel

robbe — Mon, 11 Apr 2016 08:22:38 +0000

> It is clearly an ambitious project—
Nice understatement, there. „boil the ocean“ seems more apropriate.

Am I the only one that thinks about PHP’s allow_url_fopen when they hear „everything is an URL“?

Oh boy, it's this season again

eternaleye — Mon, 11 Apr 2016 04:59:45 +0000

To reply to your footnotes first:

> [0] it does, in programs where there's no unsafe sections, and the stdlib has those out of necessity. The road to NIH is paved with concerns for purity.

The thing "total absence of unsafe" thing is from a proof about the transitively safe form of Rust, which proves that a total lack of unsafe is *sufficent*, not that it is *necessary*. There is active, ongoing work to improve on this result: http://plv.mpi-sws.org/rustbelt/

In addition, even with the use of unsafe, it still constrains the unsafe behavior significantly - though this is only valid in combination with privacy, the stdlib uses them in concert in a responsible manner. This enables the language to have a considerably smaller TCB that required auditing. See also, http://huonw.github.io/blog/2014/07/what-does-rusts-unsaf...

> [1] such as hype

Here I agree with you - in particular, that the hypothetical security advantages of microkernels are moot without a security _model_ in which to evaluate them. For that reason, I am considerably more excited by seL4 (and by extension, Robigalia) - seL4 has a strong security model, a formal proof its spec satisfies that, and a formal proof (on ARMv6 so far, but more in progress) that the implementation - all the way down to the machine code - implements that faithfully. Pairing that with a userspace written in Rust, as Robigalia[3] seeks to, further aids the goal of building reliable systems. In addition, seL4 is a modern microkernel, with performant IPC at its core and far more minimal design than the (IMO rather Mach-like, or more maximal yet) Redox design.

> [2] which, as I recall (for the Java incarnation anyway, the one Sun was going to try on thin clients), while they did do away with invalid pointer accesses, remained vulnerable to all other categories of exploit; so below the line it was uncomfortable and didn't really help.

I will note that Rust's guarantees are considerably stronger: In particular, while Java does away with actual null pointer accesses, it retains null objects with much the same semantics (which Rust avoids via strict reference lifetimes and the Option<T> type - essentially the Maybe monad), data races (which Rust avoids via strict ownership in its type system), and - if you're referring to JavaOS - it predated Java 1.3, much less 1.5 which introduced generics, and thus would have had to be downcasting from Object and so forth, introducing runtime type errors.

Beyond that, I do broadly agree with you that the state of microkernels has advanced a long way since the first generation, and repeating the same mistakes doesn't advance the art so much.

But just as history has shown that the first generation of microkernels could not live up to their promises, it's also shown that humans are still fundamentally fallible, and that tools which help reduce error have measurable, and often significant, effects on real-world reliability. I certainly don't think either microkernels or Rust are a write-off as they are today (the whole L4 family is succeeding in the world as a foundation for real-time systems, and seL4 has provable worst-case execution time guarantees, along with confinement and resource isolation.)

[0]: NMF
[1]: NMF
[2]: NMF
[3]: https://robigalia.org

Oh boy, it's this season again

ksandstr — Mon, 11 Apr 2016 03:12:14 +0000

It's a new first-generation microkernel. How quaint! Young people taking the time to study their elders' mistakes by committing them from scratch.

"Limited attack surface", sure, that's noble in the abstract -- however, an architectural sleight-of-hand that moves responsibility out of the theoretically powerful ring 0 matters for zilch when privileged processes are just as subject to compromise outside the kernel proper as they are within it. This kind of design justification makes redundant the choice of language (or vice versa): Rust, a tool that promises absolute memory safety by straightjacketing the programmer, and which should therefore eliminate the desirability of moving stuff out of ring 0 for security reasons in the first place. So either Rust doesn't do what it said on the tin[0], or these people are fawning over microkernel designs for reasons[1] that've gone without proper analysis.

And look, it parses URIs and everything. Certainly there's never been security compromise due to arbitrary-length string processing, right?

It seems that the Redox team is chasing after 1st-generation microkernel goals (viz. increased security and reliability by applying the MMU to a subset of kernel functions) with 1st-generation methods (writing things into ring 0, then moving them out using an ad-hoc interface) and recent tools designed to solve security and reliability at the level of implementation language. Not unlike older experiments conducted in Java, and later C#[2]. It's like deciding that the baseball bat isn't doing enough by itself, that it needs a turn or twenty of rusted razorwire on it, and might as well substitute something with a six-digit Scoville rating for lubrication while they're at it. And you have to wear a dunce cap upside down, too.

All this being said, it's good that tools from the pathological corner are used to explore silly designs. This way they'll knock two things off the chart of things that the next generation of misguided-but-well-informed youths might otherwise be tempted to try again. Who knows, maybe there's even an unrelated but interesting advantage one day; holding one's breath doesn't kill, so why not do that while spinning around?

[0] it does, in programs where there's no unsafe sections, and the stdlib has those out of necessity. The road to NIH is paved with concerns for purity.
[1] such as hype
[2] which, as I recall (for the Java incarnation anyway, the one Sun was going to try on thin clients), while they did do away with invalid pointer accesses, remained vulnerable to all other categories of exploit; so below the line it was uncomfortable and didn't really help.

Redox: a Rust-based microkernel

smoogen — Fri, 08 Apr 2016 01:11:15 +0000

The OS looked really good until it got to here:

To start with, ZFS is planned as the filesystem of choice for Redox, which means writing a compatible implementation in Rust or adapting the existing open-source version (OpenZFS)

Is that a real deep plan or someone just posted it to the wiki that anyone can write to? I say this because this is a HUGE undertaking and seems to be like a leftturn to try and implement a filesystem in a different language which requires experts to keep working in C.

It is also these sorts of big things without resources which took HURD from being something that might have been possible in 1994 to something that is sort of usable in limited settings in 2016.