Hacker News Reader

Comment by Animats | Hacker News Reader

I'm looking forward to seeing the major security-critical libraries being rewritten in Rust, even if they are then often called from C. Especially OpenSSL/LibreSSL, which is a mess inside, has way too much legacy code, and too many ways to turn encryption off, log keys, or weaken checks.

View on HN

Up to this point we've been encouraging people to not go wild implementing crypto et al in Rust simply because memory safety is not the only attack vector and we need to carefully consider language extensions and guarantees that would accommodate security-critical code.

That said, I do personally think that Rust will one day be an excellent language to take the place of C in implementing fundamental cryptographic libraries. But first we need domain experts to hammer on the language and provide feedback.

In the case of LibreSSL, it's probably not going to happen very soon; the OpenBSD devs are very much C programmers (and Ted Unangst already addressed this in the case of Heartbleed, though his methodology is the subject of some contention: http://www.tedunangst.com/flak/post/heartbleed-in-rust ).

While Ted's post has been criticized by a few Rust programmers (see: http://tonyarcieri.com/would-rust-have-prevented-heartbleed-... ), it still brings up the argument that one's language choice isn't a magic bullet. There's an adage (I have no idea who originated it) that's along the lines of "every 'idiot-proof' system underestimates an idiot's ability to break things", and that's worth considering here. Rust prevents a lot of bugs, but it's not a guarantee of security. One needs to understand the actual problem that needs solved, and this is where the OpenBSD devs are focusing with LibreSSL (and their various other projects); their security track record stands as a good testament of that notion of understanding trumping language choice.

This isn't to say that I disagree with you. Rust is readily poised to replace C in a lot of contexts (IIRC, one of the obstacles right now is the use of a different allocator, so trying to use a Rust library from C results in some performance overhead), and it would be nice to see it used in a lot more projects. Just bear in mind that moving to Rust isn't the only step that would be required to fix these sorts of security bugs.

Of course moving to Rust (or Go) won't fix all security bugs.

It will though stop ordinary random code having remote code execution or spurious data leak bugs.

That is really significant. It needs cheering and encouraging now, and soon it needs forcing.

Quite true.

Memory safe languages aren't bug free in terms of security bugs, as there are also logical errors, as shown by many Java exploits.

However, removing the typical C memory corruption errors out of the picture is already quite an improvement.

Rust and other system programming languages have more probability to succeed outside classic UNIX systems though, as UNIX and C go hand-in-hand and I doubt that will ever change.

The only non-classic UNIX is Mac OS X and it already has its own "Rust".

Well, the nice thing about Rust is that it's at least theoretically possible to swap out C with Rust without affecting very many things (at least not negatively, other than the duplicate allocators IIRC), so a Rusty Unix is at least plausible.

I would love to see this too, but it's not going to happen until Rust is as portable as C, which won't happen until it compiles to C, IMO.

I suspect you can have this already exists if you want it bat enough, given that rust generates llvm bitcode, and there is an llvm-cbe "target" architecture that just generates C.

The results probably won't be well-optimized, though; C isn't actually very portable at this level, there's too much implementation-defined behavior that needs to be taken into account. You'll probably spend as much effort trying to robustly handle the quirks and deficiencies of some obscure platform's compiler than doing an LLVM backend for the processor...

The LLVM C backend was removed in LLVM 3.1. But the Monster has been reanimated by [0]/[1]!

I wonder if anyone has updated the Cell SPU backend that was eventually removed. That is one of my favorite architectures. =)

[0]: https://github.com/draperlaboratory/llvm-cbe

[1]: http://thread.gmane.org/gmane.comp.compilers.llvm.devel/7594...

This could give a kick to Rust. According to recent news they are going to have a stable syntax + features for a while. http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html http://blog.rust-lang.org/2014/10/30/Stability.html

Reply on news.ycombinator.com