Hacker News Reader

Comment by MichaelGG | Hacker News Reader

How many of those new protections listed (DEP, ASLR, page 0 mapping) are still useful with a system like Rust? Cause it seems like a hell of a lot of effort is going into hardening the environment cause the code is just that leaky, but I'm probably misunderstanding something.

View on HN

Theoretically if you had a kernel written in Rust, I suppose you could implement the system call interface such that all pointers passed to the kernel from user space would be considered "borrowed" under the Rust type system, and then have all your "return to user space" mechanisms recognised by the compiler as terminating their lifetime.

I'm not sure if that's enough though, considering that, in general, the kernel can't assume anything passed to it by reference via a system call isn't mutated by another userland thread. Furthermore, even if everything were written in Rust, the kernel can't just trust that a userland process was actually compiled in a way that faithfully employed Rusts compile-time safety guarantees... so I think any notion of shared garbage collection is tricky without a program loader that did code verification.

Microsoft have done some work in this area with their Singularity and Midori projects[0]. Singularity in particular eliminates hardware isolation between processes.

I think the simple answer here is that the kernel should be copying anything passed to it by reference if it intends to do anything beyond a single atomic read operation. This is why, on Linux for instance, send() can't return to user space until the data has been copied in to kernel controlled memory, and why we have nice things like splice() and sendfile() to deal with the performance hit of doing so for common cases.

[0] https://en.wikipedia.org/wiki/Midori_%28operating_system%29

Removing hardware isolation in general is not a good idea. There are enough hardware errors to cause problems. You don't want a bitflip to cause everything on your server to become corrupted. (Bitflips can be reduced by using ECC ram. But still, the principle remains.) (Worse: you don't want someone to be able to take over your entire physical server from one of the virtual servers)

One option would be for the kernel to temporarily mark the page(s) referenced as read-only, and do copy-on-write where necessary. This would prevent the (presumably) common case of not having the page modified by another thread while the kernel processes the data to not incur the delay of copying the data. Might only be worth it for larger amounts of data, though.

None of these protections is 100% reliable; they make exploiting harder, but they often don't make it impossible.

Rust is memory-safe so assuming the rust implementation is correct, it should never lead to executing user data. OTOH there have been plenty of e.g. JVM exploits over the years, which were mitigated by DEP, and the JVM offers the same kind of safety guarantees.

All of those are band aids that wouldn't be needed in first place if the world had adopted something like Modula-2 (just a possible example) instead of copying UNIX and bringing C along for the ride.

Rust would help as long as unsafe code blocks aren't exposed to the outside world. Which still seems a bit hard to accomplish, as many Github projects suffer from unsafe overdose.

However, even memory safe languages suffer from logical errors.

GM once used an in-house version of Modula-2 for its embedded controllers [1]. I wonder if they regret the switch to C in light of all the bad press about remote vulnerabilities[2][3]. It sounds like the biggest problem is that features are exposed without any protection, though.

[1] https://en.wikipedia.org/wiki/Modula-2#Modula-GM

[2] http://www.cbsnews.com/news/car-hacked-on-60-minutes/

[3] http://www.caranddriver.com/features/can-your-car-be-hacked-...

Reply on news.ycombinator.com