Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

This is an excellent summary Steve, it also points out one of the challenges of 'System' languages, which is the requirement for 'unsafe.'

One of the first things I did when I started working on Oak (which became Java) was to see about writing an OS in it. The idea being that if you could write an OS in a 'safe' language then you could have a more reliable OS. But we were unable to write it completely in Oak/Java and that lead to some interesting discussions about what might be the minimum set of 'unsafe' actions might be required by a systems language.

Sadly we did not get to explore that very much, although I did pass it on as a possible thesis topic to some interns who came through Sun at the time. I'd be interested in your experience with what actions require 'unsafe' and if you have seen a canonical set that might point toward a process to get to a 'safe' OS.

View on HN

Glad you liked it, Chuck.

Some of my closest friends in college specialized in operating systems, and we (mostly them) worked on http://xomb.org , an exokernel in D. I'd hope that today we'd choose Rust instead.

Julia Evans has been writing _fantastic_ series about a kernel in Rust: http://jvns.ca/blog/categories/kernel/

As she says "This is typical of a lot of Rust code I’m writing – I need to write a lot of unsafe code."

I'll have to give this 'minimum set' idea some thought. I think that safety will be more useful for things like kernel modules than in the kernel itself, though I'm not sure why I think that, exactly. Hmmmmm...

  > I need to write a lot of unsafe code.

To contrast with application-level code, pcwalton has measured that less than 1% of Servo's code is contained within `unsafe` blocks.

Exactly, and of course this leads me to wondering about computer architectures that "require" unsafe things in their kernels, versus things like Multics where the OS and hardware co-operated at some level to make things safe. Lots of interesting questions.

One possibility might be to add hardware support for fine-grained capability security - http://www.cl.cam.ac.uk/research/security/ctsrd/

Would that help? Wouldn't the use of a safe language make hardware-level memory protection less important, not more?

For reference, the following actions are what are enabled within `unsafe` blocks in Rust:

1. Dereferencing raw pointers (a.k.a. "unsafe" pointers). Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

2. Calling a Rust function that has been marked with the entirely-optional `unsafe` keyword.

3. Calling an external function via the C FFI, all of which are automatically considered unsafe.

>Note that's just dereferencing: there's nothing inherently unsafe about just creating and passing around the pointers themselves.

Sure there is. Passing around multiple pointers can result in a double free and then the dangerous dereference can happen. I'm guessing the developer must be careful when writing unsafe blocks to make sure this doesn't happen.

Unsafe behaviours with raw pointers:

  - dereferencing
  - arithmetic (implemented as ptr.offset(number) in the stdlib), 
    since it is undefined behaviour for LLVM to move a pointer to
    point outside* of the object that it came from originally 
    (even without deferencing)

Everything else is OK. (Although the only other thing possible is passing it around as "black box" value.)

*One byte past the end is ok.

but they are safe until you decide to do that deferencing, otherwise they're just uint_ptrs really.

Don't points 2 & 3 together imply that anything that uses built-ins, which I assume are implemented with C FFI, is `unsafe`?

No, “unsafe” means “evaluate this unsafe block as though it were safe”. This enables Modula-style safe interfaces for unsafe implementations.

Just to clarify, using a `unsafe` block in a function does NOT mean that you have to tag that function as unsafe.

I'm not 100% sure exactly what you mean by 'built-ins', but Rust is almost entirely written in Rust. I don't think there's anything major implemented via C FFI in the compiler itself.

You'll probably be interested in the Singularity project at Microsoft Research: http://research.microsoft.com/en-us/projects/singularity/

Much of the kernel is implemented in managed code.

I remember hearing about Singularity a few years back - it sounded promising. Looking at the linked page, there doesn't seem to be anything published or presented since 2009. Anyone know what's going on with Singularity these days?

Sun eventually did JavaOS, though I'm not sure how much of its code was Java.

IBM did Jikes RVM (old name: Jalapeno) which was mostly, if not purely Java. They handled the bootstrapping problem with some clever ahead-of-time compilation + meta-programming. Even their GC is implemented in Java.

Jikes RVM was an absolutely amazing project. Superb work.

googles

Jikes RVM is an absolutely amazing project. Superb work. And i'm very glad to see it's still under somewhat active development!

http://jikesrvm.org/

Reply on news.ycombinator.com