Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by arcticbull on Saturday June 13, 2020 @02:08PM (#23511334)

Due to its strong and simple C bindings, there's no reason new kernel modules can't default to being written in Rust, and allow Rust to spread from the "outside in" to the heart of the kernel. I don't advocate wide-scale rewriting of the kernel, but I do think default-to-rust for new kernel components and modules is rational and improves the system.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by uluyol on Saturday June 13, 2020 @02:57PM (#23511736)

A mixed-language codebase will always be more complex than a single language one. So it's not just a matter of Rust integrating well-enough with the rest of the kernel, but it has to offer enough improvement for the cost to be worthwhile.

So to evaluate whether it's worth introducing rust, you'd ideally want to find a self-contained part of the kernel that is responsible for many CVEs and you'd want to show a substantial reduction of CVEs with the rewrite of just that component. Not impossible, but also not so easy.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by jfkebwjsbx on Saturday June 13, 2020 @03:49PM (#23512148)

The kernel is required to be compilable with very old versions of GCC. So unless all users/companies agree on lifting that restriction, there is not much to do. rustc is not stable nor old enough.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by ndesaulniers on Saturday June 13, 2020 @04:38PM (#23512493)

So it's currently GCC 4.6+, with patches queued to bump that to 4.8+. Also, you can use Clang. So I'm not sure how rustc being used for some parts of the kernel has anything to do with developers "restriction?"

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by ndesaulniers on Monday June 15, 2020 @05:24PM (#23533141)

Via LWN, looks like the GCC 4.8+ patches got merged into the kernel's 5.8 merge window recently, with a footnote suggesting this be bumped to GCC 4.9+.

https://lwn.net/Articles/822527/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by phkahler on Saturday June 13, 2020 @02:18PM (#23511417)

What about a Rust to C translator? It would produce "safe" C right?

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by zozbot234 on Saturday June 13, 2020 @02:26PM (#23511484)

You would also need to comprehensively annotate the Linux C headers in order to provide the information that Rust expects (e.g. for each ptr instance whether it's a "raw" pointer, a shared/exclusive reference or a piece of "owned" data, whether it can be NULL etc. etc.). This might actually get accepted upstream though. Having the kernel-build itself depend on Rust could be far more problematic, given e.g. the variety of hardware that Linux must support.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by ufmace on Saturday June 13, 2020 @04:36PM (#23512467)

I would think such a thing would be more like "compiling" rust to C. As in the C code would have no means to maintain most of the safety guarantees, rather they would be verified at compile time, and the produced C would be meant to be used unchanged. So as long as nobody ever edits the C manually, it would still presumably be safe.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by phkahler on Saturday June 13, 2020 @06:11PM (#23513254)

That's what I really meant. Write it in Rust but then output C instead of ASM. The parent is right though. A component/driver would need to use the C headers from the Rust side.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by TheDesolate0 on Saturday June 13, 2020 @02:37PM (#23511579)

Not only that, but Rust depends on LLVM.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by dijit on Saturday June 13, 2020 @03:18PM (#23511908)

Last time I looked at this comment it was flagged [dead]; I'm glad someone was able to remedy that as I was unable to upvote.

I think this is a good criticism, but might not be true forever and is certainly something to keep in mind.

As I said in the GP, Rust will not be upstreamed into the kernel- this is one of the reasons why.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by kbenson on Saturday June 13, 2020 @04:50PM (#23512592)

If a comment is dead that you think is worthwhile, you can follow the permalink to it and vouch for it. I imagine that feature is gated behind some point threshold, but my guess is whatever that threshold is you're past it.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by dijit on Sunday June 14, 2020 @02:36PM (#23520052)

Oh, nice, thanks for that. :)

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by saagarjha on Saturday June 13, 2020 @02:52PM (#23511701)

It doesn't have to, but yes, it currently pretty much requires LLVM.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by 6c696e7578 on Saturday June 13, 2020 @02:44PM (#23511636)

https://lwn.net/Articles/797828/

Perhaps the way to do it is to rewrite common bits that get CVEs, just so it doesn't happen again.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by arcticbull on Saturday June 13, 2020 @02:27PM (#23511489)

The output of the translator would be right, but messy, and someone would have to go back and clean it up. Doing that work would almost certainly introduce bugs. How many, and whether it outweighs is the question.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by gfs on Saturday June 13, 2020 @03:26PM (#23511972)

There is a lot of work being done on a translator now [0]. However, the goal is to translate C to equivalent Rust and then allow developers to intervene to migrate to safe Rust.

[0]: https://c2rust.com

EDIT: Oops, read the parent comment backwards.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by zozbot234 on Saturday June 13, 2020 @03:33PM (#23512024)

That's C to Rust, not Rust to C. (mrustc provides something like the latter, but it doesn't actually support full Rust.)

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by simion314 on Saturday June 13, 2020 @02:41PM (#23511613)

We just seen a news that Firefox is reusing Chromes regex c++ code, so from my point of view Firefox is barley pushing for Rust components but Rust fans expect the kernel to push harder. IMO when Firefox and all it's componetns/dependencies are Rustifed then I think we can ask for the kernel to attempt the same.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by gpm on Saturday June 13, 2020 @03:33PM (#23512029)

One component choosing to use a mature implementation in another browser instead of a rewrite from scratch in rust means very little.

We can look at actually statistics instead of just one random anecdote. For instance, according to [1], there are 2 million lines of rust code in firefox, 6 million lines of C++, and 3 million lines of C. Very roughly speaking that's 20% of the lines of low level language being in Rust.

Firefox only started requiring rust to be built about 3 years ago, this is a pretty breakneck pace of replacing C/C++ with rust.

[1] https://www.openhub.net/p/firefox/analyses/latest/languages_...

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by simion314 on Sunday June 14, 2020 @03:42AM (#23515828)

I personally would also check if the libraries Firefox uses are Rust, I mean the browsers this days are huge, you have image,audio,video,WebGl,pdf and a ton more features so you need all the dependencies to also be memory safe especially the ones that handle untrusted input.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by asjw on Saturday June 13, 2020 @05:37PM (#23512977)

Firefox JS engine is in C++ even though rust has been available for years now, they've said more than once that they have no plans on porting Spidermonkey to Rust.

The most recent information I've found is from a Spidermonkey Dev here on HN who said they might even port the Regex engine to Rust

That didn't happen either

https://news.ycombinator.com/item?id=18988024

Something tells me that there's more than meets the eye.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by gpm on Saturday June 13, 2020 @06:30PM (#23513387)

It seems unlikely that there is any great conspiracy at play here to me... they found a good solution to a problem, they implemented it. Spidermonkey is a highly optimized carefully examined code base, it's not easy to replace wholesale or particularly low hanging fruit to be replaced with rust.

Mozilla is working on replacing the wasm compiler, and eventually the compiler for "ion MIR" (an intermediate langauge that js is compiled to), with cranelift, a rust implementation of a compiler backend. See [1] for pretty pictures of this.

It's been possible to use this backend to some extent since 2018 [2]. The best place I was able to find in the last 5 minutes to describe the current state of the integration is the doc comment at the top of this file [3].

In other words it looks like spidermonkey is not not being ported, it's just not being entirely ported yet.

[1] https://github.com/bytecodealliance/wasmtime/blob/master/cra...

[2] https://old.reddit.com/r/rust/comments/9mvnrk/in_firefox_nig...

[3] https://github.com/mozilla/gecko-dev/blob/master/js/src/wasm...

Edit: Another component of spidermonkey that is being rewritten in rust is the JS parser, that project is called smooshmonkey. You can read about it in the spidermonkey news letters [4] [5] [6], and there's an nice comment describing it at the top of this reddit thread [7]

[4] https://mozilla-spidermonkey.github.io/blog/2020/01/10/newsl...

[5] https://mozilla-spidermonkey.github.io/blog/2020/03/12/newsl...

[6] https://mozilla-spidermonkey.github.io/blog/2020/05/11/newsl...

[7] https://old.reddit.com/r/rust/comments/h0ddpi/smooshmonkey_n...

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by cma on Saturday June 13, 2020 @02:47PM (#23511657)

If Firefox wrote a new regex module and didn't use Rust that would contradict the poster's advice, but them using an existing mature bit of coded doesn't seem to prove much.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by simion314 on Saturday June 13, 2020 @03:02PM (#23511788)

What Firefox done makes sense, but it does not look good to the idea you can just rewrite in Rust function by function. A regex engine seems to me a thing that is easy to TDD, so I would expect if rewriting in Rust is that easy Firefox would rewrite the most dangerous parts in Rust already (I assume regex is used with untrusted input but I am clueless so i could be wrong). IMO the giant army of Rust fans should put their energy working on Firefox or donating to have Firefox rewriten before 2030, because the story that is heavily promoted is that you can rewrite shit in Rust super easy, function by function, etc but the reality is different.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by frenchy on Saturday June 13, 2020 @03:25PM (#23511960)

Firefox didn't choose the C++ regex implementation because rewriting pieces of code with well defined interfaces is hard. It was for a few reasons: 1) at the time they made the decision, there was no existing rust regex library that matched the way that JavaScript worked, 2) they didn't want to write their own/rewrite existing code because regex libraries are complicated beasts, 3) the C++ code is mature and well tested, so the primary benefit of a rust implementation would be more speed (because it's easier to safetly reason about shared data) they didn't think that optimizing the regex engine was a priority.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by simion314 on Saturday June 13, 2020 @03:29PM (#23511991)

It makes sense, I am still a bit disappointed (so is a subjective thing) hopefully the RIR crowd gets more rational and reads your explanation and see that is not so easy.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by FuckButtons on Saturday June 13, 2020 @05:32PM (#23512932)

>. A regex engine seems to me a thing that is easy to TDD Why go to all that effort when the thing you need is already available? I don't think there are that many people that argue that everything, even the stuff that works fine and doesn't have issues, should be re-written just because rust exists.

[ Parent | on HN ]

Re:Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe S... by zozbot234 on Saturday June 13, 2020 @03:16PM (#23511890)

C code can be rewritten function-by-function, even programmatically via c2rust. C++ is a bit messier and even the FFI interoperability story wrt. Rust is not quite complete.

[ Parent | on HN ]