Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is not a matter of opinion. The collection of CVEs reported (which represent an unknown fraction of faults that could in principle be found) clearly identify which are memory usage bugs of a type that could be prevented by a compiler. My reading is that the large majority are not.

If the demonstrated complacency of Rust coders toward potential bugs is factored in, and inexperience with the language among potential reviewers, use of Rust in the kernel could actually increase the number of exploitable faults. I do not assert this would certainly occur, but no one can demonstrate it would not.



> If the demonstrated complacency of Rust coders toward potential bugs

lol what?

This is so very the opposite of my 6+ years of experience in Rust, where the community has a serious focus on testing, and great tooling support for it as well.

I honestly can't take anyone seriously who thinks that adding Rust to the kernel will increase security bugs. I just can't imagine they know anything about Rust, security, or the kernel.


I judge based on the tide of opinion that washes up, everywhere Rust is even mentioned, that bugs in Rust code are physically impossible. That is the whole value proposition of the language, as presented. Anyone hinting that bugs are still possible in Rust gets downvoted to oblivion (as here).

I do not doubt that there are Rust coders who are especially vigilant about introducing bugs, but they certainly are, as in all times and places, the exception.


> that bugs in Rust code are physically impossible

This isn't a real thing either. I see it asserted all the time on HN and it's hilarious.

> Anyone hinting that bugs are still possible in Rust gets downvoted to oblivion (as here).

90% of the time it's because the person is making a stupid point. 10% of the time it's the community being annoying.

So just to reiterate, you're basing this on being barely an observer on forums, and I'm basing this on multiple years of professional rust development.


for another operating system, we have ~70% of security bugs being memory safety issues (https://www.zdnet.com/article/microsoft-70-percent-of-all-se...). sounds like a decent majority to me.


There's a similar effect as Amdahl's law with these. Only after programmers come to their senses and opt to take care of that 70%, we get to the remaining part of the pie and its subdivisions, and can start thinking about the actually interesting part of engineering secure systems.

The overwhelming prevalence and impact of memory safety bugs has retared development of solutions for the remaining, nontrivial problems for many decades, by consuming so much of the attention.


Windows is Windows, and Microsoft is Microsoft. Extrapolation from those to anywhere else in the universe does not generate a plausible argument.


how about

https://www.chromium.org/Home/chromium-security/memory-safet...

https://langui.sh/2019/07/23/apple-memory-safety/

these companies apply things like sandboxing and fuzzing to reduce the incidence of memory unsafety bugs, and yet they're finding a majority of their security bugs being memory unsafety. if you can't find memory unsafety in your c++ code, it's because your code isn't worth attacking.


These, also, are not Linux. If in fact Linux CVEs matched such a pattern, somebody would be certain to be jumping up and down pointing it out.


hey, whaddya know, i just stumbled upon this today https://twitter.com/geofft/status/1132739184060489729




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: