9 ms·

>> we have yet to see tangible benefits of using Rust. As a long-time C and C++ programmer, I have to disagree. C and C++ have been great and so much software

>> we have yet to see tangible benefits of using Rust. As a long-time C and C++ programmer, I have to disagree. C and C++ have been great and so much software has been written using them, but the time has come to move on. The majority of software security bugs are due to the lack of controls in C and C++. This is not an opinion or an anecdote, it is a fact: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se... https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs... https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... Operating systems need to be secure. Operating system kernels even more so. The Linux kernel could move to Rust or Ada or Nim or something else, but keeping it in C is an invitation for continued security problems: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux+kernel%22 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux+ke...

sigzero 4y ago
I doubt very much if it is going to move off of C. Linus isn't going to do that.
- thesuperbigfrog 4y ago
  >> I doubt very much if it is going to move off of C. Time will tell, but Rust support for use in Linux kernel development is increasing. If it solves problems and is easier to use, it will gain traction and see wider adoption.
- Analemma_ 4y ago
  Linus is more pragmatic than you think. He's cautious and resistant to faddish trends, but he can be convinced. I think Rust has a ways to go before it's ready for the kernel proper (the architecture support being the big thing), but if it does get there I think he can be open to the idea of a switchover.
- krelian 4y ago
  To be frank I have no idea what his opinion of Rust is but if there is a guy who has it in him to make that kind of decision it's Linus. He changed software twice he can do a third time.
netr0ute 4y ago
C++ doesn't have to be unsafe anymore, as it now has features that make it just fine to use without manual memory control.
- augusto-moura 4y ago
  Well, until the statistics numbers change this idea is just on the opinion realm. Maybe it's better now, but the numbers don't lie
  - netr0ute 4y ago
    I would bet $1 that 99% of memory leaks are from legacy C, or C++ where the code monkey forgot to use memory safe features.
    - dagmx 4y ago
      Memory leaks aren’t safety issues
      - tonto 4y ago
        denial of service can exploit some memory leaks i imagine
        Hemospectrum 4y ago
        Memory leaks are bad, but they can't break type safety. Buffer overflows and use-after-free are categorically more dangerous.
        dagmx 4y ago
        In that scenario a memory leak isn’t any more unsafe than any other program data that’s in memory.
    - insanitybit 4y ago
      Ignoring that memory leaks are not the issue, no, indeed new bugs are introduced to kernel code constantly.
optymizer 4y ago
In my opinion, if you can't handle a sharp knife, you've got no business being in the kitchen. It seems that the primary security argument is that N-1 types of issues is better than N. I would argue that the formula is really N - 1 + X, and that we're all focused on the very positive "-1" aspect, but what's the value of X? In other words, what are we trading off by using Rust instead of C in the kernel? Why trade a language which we know the pitfalls of (N) for a language that's potentially adding X pitfalls, and if you're going to argue that Rust has no pitfalls, then to me that's just the kool-aid talking. Realistically, in a new language, you don't know if X is 0, and adding unknown unknowns are precisely the one thing you do not want in a critical piece of software like a kernel. Furthermore, if OSes need to be secure, and system kernels need to be even more secure, which we all agree on, then all you're doing by advocating against using a stable language with known pitfalls like C is you're lowering the knowledge bar ("hey look I can write kernel code now because I won't introduce memory issues!"), thereby increasing the pool of people who will make logical mistakes out of lack of knowledge, which you will not eliminate with static analysis. C is not ideal, but it's a practical way to gate the entry to critical software, because 1. C, the language, has a handful of pitfalls, while the software written in any language has orders of magnitude more avenues to exploit it (e.g. access permissions, communication protocols, environmental assumptions, etc). 2. Most of what's difficult in C stems from the realities of dealing with computer architectures. If you can't be bothered to learn the ins and outs of C, you're not fit to write portable low level machine code in a kernel just yet. Just because we can be reasonably sure you won't introduce a memory problem is not sufficient guarantee that you won't do stupid things in the kernel that will cause security problems in a different way. In the end, I hope I'm wrong about Rust and X is 0, but it seems to me that there's a much better way to ensure we get to an N-1 situation without an X: introduce the borrow checker in C. Why throw the baby with the bath water? The software industry is very aware by now of the pitfalls of rewriting a project instead of making incremental changes. Bring the memory safety to C. You get 50 years of stability and well documented issues, while still removing a whole class of bugs. Now that would be an absolute win.
- Cthulhu_ 4y ago
  But Rust builds on top of that 50 years of experience, stability and known issues and has solved a lot of them. What does C have to offer that Rust doesn't? I don't think it's fair to blame the issues that code written in C can have on incompetence.

sigzero 4y ago

I doubt very much if it is going to move off of C. Linus isn't going to do that.

thesuperbigfrog 4y ago
>> I doubt very much if it is going to move off of C. Time will tell, but Rust support for use in Linux kernel development is increasing. If it solves problems and is easier to use, it will gain traction and see wider adoption.
Analemma_ 4y ago
Linus is more pragmatic than you think. He's cautious and resistant to faddish trends, but he can be convinced. I think Rust has a ways to go before it's ready for the kernel proper (the architecture support being the big thing), but if it does get there I think he can be open to the idea of a switchover.
krelian 4y ago
To be frank I have no idea what his opinion of Rust is but if there is a guy who has it in him to make that kind of decision it's Linus. He changed software twice he can do a third time.

netr0ute 4y ago

C++ doesn't have to be unsafe anymore, as it now has features that make it just fine to use without manual memory control.

augusto-moura 4y ago
Well, until the statistics numbers change this idea is just on the opinion realm. Maybe it's better now, but the numbers don't lie
- netr0ute 4y ago
  I would bet $1 that 99% of memory leaks are from legacy C, or C++ where the code monkey forgot to use memory safe features.
  - dagmx 4y ago
    Memory leaks aren’t safety issues
    - tonto 4y ago
      denial of service can exploit some memory leaks i imagine
      - Hemospectrum 4y ago
        Memory leaks are bad, but they can't break type safety. Buffer overflows and use-after-free are categorically more dangerous.
      - dagmx 4y ago
        In that scenario a memory leak isn’t any more unsafe than any other program data that’s in memory.
  - insanitybit 4y ago
    Ignoring that memory leaks are not the issue, no, indeed new bugs are introduced to kernel code constantly.

optymizer 4y ago

In my opinion, if you can't handle a sharp knife, you've got no business being in the kitchen. It seems that the primary security argument is that N-1 types of issues is better than N. I would argue that the formula is really N - 1 + X, and that we're all focused on the very positive "-1" aspect, but what's the value of X? In other words, what are we trading off by using Rust instead of C in the kernel? Why trade a language which we know the pitfalls of (N) for a language that's potentially adding X pitfalls, and if you're going to argue that Rust has no pitfalls, then to me that's just the kool-aid talking. Realistically, in a new language, you don't know if X is 0, and adding unknown unknowns are precisely the one thing you do not want in a critical piece of software like a kernel. Furthermore, if OSes need to be secure, and system kernels need to be even more secure, which we all agree on, then all you're doing by advocating against using a stable language with known pitfalls like C is you're lowering the knowledge bar ("hey look I can write kernel code now because I won't introduce memory issues!"), thereby increasing the pool of people who will make logical mistakes out of lack of knowledge, which you will not eliminate with static analysis. C is not ideal, but it's a practical way to gate the entry to critical software, because 1. C, the language, has a handful of pitfalls, while the software written in any language has orders of magnitude more avenues to exploit it (e.g. access permissions, communication protocols, environmental assumptions, etc). 2. Most of what's difficult in C stems from the realities of dealing with computer architectures. If you can't be bothered to learn the ins and outs of C, you're not fit to write portable low level machine code in a kernel just yet. Just because we can be reasonably sure you won't introduce a memory problem is not sufficient guarantee that you won't do stupid things in the kernel that will cause security problems in a different way. In the end, I hope I'm wrong about Rust and X is 0, but it seems to me that there's a much better way to ensure we get to an N-1 situation without an X: introduce the borrow checker in C. Why throw the baby with the bath water? The software industry is very aware by now of the pitfalls of rewriting a project instead of making incremental changes. Bring the memory safety to C. You get 50 years of stability and well documented issues, while still removing a whole class of bugs. Now that would be an absolute win.

Cthulhu_ 4y ago
But Rust builds on top of that 50 years of experience, stability and known issues and has solved a lot of them. What does C have to offer that Rust doesn't? I don't think it's fair to blame the issues that code written in C can have on incompetence.