6 ms·

Redox is still very much a prototype and shows you can't simply slap "safe" Rust together and magically conjure up a kernel and OS: https://gitlab.redox-os.org/

Redox is still very much a prototype and shows you can't simply slap "safe" Rust together and magically conjure up a kernel and OS: https://gitlab.redox-os.org/redox-os/redox/issues/1136 https://gitlab.redox-os.org/redox-os/redox/issues/1136

gpm 8y ago
So, no one anywhere is claiming you can write a kernel in purely safe code. It fundamentally needs to access arbitrary memory locations which is unsafe. That said, I don't think any of the issues in that thread are related to unsafety. It's perfectly safe to panic. None of those bugs are memory corruption, arbitrary code execution, or so on, which is what safety tries to protect against.
- paavoova 8y ago
  But people are claiming you can't write a safe kernel in C, and point out safe languages which should be adopted in its place. This misses the point that, just like the theoretical safety of C is 100% safe, the theoretical safety of Rust as a low-level language is zero. Those are all bugs produced essentially on request. That doesn't bode well for the security and robustness of the project. The end user doesn't care whether the class of bug is memory related or whatever else if the end consequences are the same. Despite having the benefit of safety and the decreased burden on the programmer this offers, bugs still abound in Redox, which points to it being written in Rust as incidental at best.
  - empath75 8y ago
    Nobody has ever said that it is impossible to write buggy code in Rust. It merely makes security guarantees about certain classes of bugs, and the use of unsafe code blocks makes it easier to isolate cases where those classes of bugs can occur.
  - roca 8y ago
    Don't gloss over the distinction between security and robustness. The consequences of panics and memory corruption are very much NOT the same. The former means a reboot, which is annoying; the latter means corrupted or exfiltrated data or a hostile takeover of the system.
  - weberc2 8y ago
    It's hard to tell what argument you're making, but it sounds something like "All languages whose safety is less than 100% are equally safe". Obviously Rust is safer than C (both in theory and in practice, both for high- and low-level programming). NOTE: Observers should resist the temptation to interpret this post as an endorsement for the "rewrite everything in Rust!" crowd.
  - pjmlp 8y ago
    Just go watch the talks from Linux Security Summit 2018. https://www.youtube.com/watch?v=KUCwiQZuasA&list=PLbzoR-pLrL6oa4x78bHssxmGAw_ns1Tm2 https://www.youtube.com/watch?v=KUCwiQZuasA&list=PLbzoR-pLrL... Linux kernel developers are the first ones to acknowledge that something has to be done to change the course of CVE in the Linux kernel. Just in 2017, 68% of exploits were caused by out of bounds errors.
- nickpsecurity 8y ago
  They aren't. Some verification experts and I are: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/pldi117-yang.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... https://news.ycombinator.com/item?id=17051131 https://news.ycombinator.com/item?id=17051131 It's safe if you can prove it's safe. Even C with Frama-C. If the type system can't do it, use an external tool to do it. Tools exist, automated and manual, for doing such safety proofs on high-, low-, assembler-, and microcode-level software. There's a long tradition of verification in hardware, too. Rockwell-Collins even uses the tools common for hardware to verify software and hardware together. http://www.ccis.northeastern.edu/home/pete/acl206/slides/hardin.pdf http://www.ccis.northeastern.edu/home/pete/acl206/slides/har... The real problem, aside from just limited resources to build tooling, is a mindset of trying to rely on one tool for safety instead of mixing up different approaches to get their benefits.
nixpulvis 8y ago
I think you could probably go as far as to say that, with todays understanding of an OS, one can't simply slap together an OS given any medium. LOL
kjeetgill 8y ago
I wonder how much confusion could be avoided if the term was unchecked or unrestricted instead of unsafe? Though I suppose unsafe establishes that some caution is required.

gpm 8y ago

So, no one anywhere is claiming you can write a kernel in purely safe code. It fundamentally needs to access arbitrary memory locations which is unsafe. That said, I don't think any of the issues in that thread are related to unsafety. It's perfectly safe to panic. None of those bugs are memory corruption, arbitrary code execution, or so on, which is what safety tries to protect against.

paavoova 8y ago
But people are claiming you can't write a safe kernel in C, and point out safe languages which should be adopted in its place. This misses the point that, just like the theoretical safety of C is 100% safe, the theoretical safety of Rust as a low-level language is zero. Those are all bugs produced essentially on request. That doesn't bode well for the security and robustness of the project. The end user doesn't care whether the class of bug is memory related or whatever else if the end consequences are the same. Despite having the benefit of safety and the decreased burden on the programmer this offers, bugs still abound in Redox, which points to it being written in Rust as incidental at best.
- empath75 8y ago
  Nobody has ever said that it is impossible to write buggy code in Rust. It merely makes security guarantees about certain classes of bugs, and the use of unsafe code blocks makes it easier to isolate cases where those classes of bugs can occur.
- roca 8y ago
  Don't gloss over the distinction between security and robustness. The consequences of panics and memory corruption are very much NOT the same. The former means a reboot, which is annoying; the latter means corrupted or exfiltrated data or a hostile takeover of the system.
- weberc2 8y ago
  It's hard to tell what argument you're making, but it sounds something like "All languages whose safety is less than 100% are equally safe". Obviously Rust is safer than C (both in theory and in practice, both for high- and low-level programming). NOTE: Observers should resist the temptation to interpret this post as an endorsement for the "rewrite everything in Rust!" crowd.
- pjmlp 8y ago
  Just go watch the talks from Linux Security Summit 2018. https://www.youtube.com/watch?v=KUCwiQZuasA&list=PLbzoR-pLrL6oa4x78bHssxmGAw_ns1Tm2 https://www.youtube.com/watch?v=KUCwiQZuasA&list=PLbzoR-pLrL... Linux kernel developers are the first ones to acknowledge that something has to be done to change the course of CVE in the Linux kernel. Just in 2017, 68% of exploits were caused by out of bounds errors.
nickpsecurity 8y ago
They aren't. Some verification experts and I are: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/pldi117-yang.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... https://news.ycombinator.com/item?id=17051131 https://news.ycombinator.com/item?id=17051131 It's safe if you can prove it's safe. Even C with Frama-C. If the type system can't do it, use an external tool to do it. Tools exist, automated and manual, for doing such safety proofs on high-, low-, assembler-, and microcode-level software. There's a long tradition of verification in hardware, too. Rockwell-Collins even uses the tools common for hardware to verify software and hardware together. http://www.ccis.northeastern.edu/home/pete/acl206/slides/hardin.pdf http://www.ccis.northeastern.edu/home/pete/acl206/slides/har... The real problem, aside from just limited resources to build tooling, is a mindset of trying to rely on one tool for safety instead of mixing up different approaches to get their benefits.

nixpulvis 8y ago

I think you could probably go as far as to say that, with todays understanding of an OS, one can't simply slap together an OS given any medium. LOL

kjeetgill 8y ago

I wonder how much confusion could be avoided if the term was unchecked or unrestricted instead of unsafe? Though I suppose unsafe establishes that some caution is required.