5 ms·

Using C sounds like it will bring a whole new list of exploits with it. Not good!!

vodou 4y ago
C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.
- vfclists 4y ago
  I guess "experienced C programmers" must be short supply although they have been writing C for years.
- c7DJTLrn 4y ago
  That would explain all the vulnerabilities in systemd and Linux. They just aren't experienced enough. Linus needs to get in touch with an expert.
  - tinus_hn 4y ago
    I’m looking forward to your efforts in rewriting it in Rust
    - tptacek 4y ago
      So is everyone else! Can't happen soon enough.
- jcranmer 4y ago
  SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed. It still accumulates CVEs: https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html.
  - vodou 4y ago
    Are you aware of a way to develop fault free code? Please share this knowledge then, please.
    - jcranmer 4y ago
      It's easy to develop fault-free code: just redefine all those faults as (undocumented) features! That's not a helpful answer, but it's basically the same thing you're doing--redefining memory safety vulnerabilities that would be precluded entirely by writing in memory-safe languages as programmer faults.
    - tptacek 4y ago
      He's aware of a way to develop memory-corruption-fault free code, obviously.
  - eesmith 4y ago
    As I recall, one of the advantages of C over Rust is that the SQLite authors have the tooling to do 100% branch coverage testing of the compiled binaries in C. They tried Rust, but Rust inserts code branches they are unable to test. The tradeoff then is the small number of bug causing the denial of service bugs listed, vs. not having 100% branch coverage. And they chose the latter. (The authors also believe Rust isn't portable enough, not handles out-of-memory errors well enough - https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a_safe_language_ https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a... .)
- wglb 4y ago
  The effort is massive and the experience to do so at scale is very rare.
midislack 4y ago
Stop this.
WesolyKubeczek 4y ago
Of course, let's better use a PostScript interpreter also written in C, so your exploits leveraging both at least look like art.
srvmshr 4y ago
When people write code which doesn't have memory safety & lacks the compactness needed for a mature product, it is not C language's fault C is a well tested compact language - the fact that Linux kernel, BSD kernels, device drivers and a whole lot of games and physics engines are written for performant systems is a testament to it's reliability. Additionally, I think it's the sane move. A language which is hot cake today (Yes, Rust) may or may not be in fashion 5 years from now when there's a new hotcake. Choices are made keeping 10-15 years project development in mind
- pjmlp 4y ago
  When Michael Abrash wrote his books, C compilers weren't known for the quality of their blazing machine code. It also has a proven record that no matter what, exploits are bound to happen, making the whole industry turn into hardware memory tagging as the ultimate solution to fix C.
  - srvmshr 4y ago
    Memory exploits in Rust : Yes much less. That's where the world is (hopefully) headed to. But then a lot of people would disagree on "Lets jump on the <new-hot-language> bandwagon ASAP". Even the transition to parts of Linux kernel components in Rust is slow and cautious. In that sense, C is still a wide choice. Plus there are a lot of people actively working on C. Rust is only but picking up. it's more likely people will write buggy code on a new language than something which has been around for a while.
    - pjmlp 4y ago
      No need to bring Rust into this talk, Modula-2 from 1978 would already sort out most of C's mistakes, or even JOVIAL from 1958. C became a forced choice thanks to UNIX's free beer, and like JavaScript with the Web, it tainted us all.
deleted 4y ago
[deleted]

C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.

vfclists 4y ago
I guess "experienced C programmers" must be short supply although they have been writing C for years.
c7DJTLrn 4y ago
That would explain all the vulnerabilities in systemd and Linux. They just aren't experienced enough. Linus needs to get in touch with an expert.
- tinus_hn 4y ago
  I’m looking forward to your efforts in rewriting it in Rust
  - tptacek 4y ago
    So is everyone else! Can't happen soon enough.
jcranmer 4y ago
SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed. It still accumulates CVEs: https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html.
- vodou 4y ago
  Are you aware of a way to develop fault free code? Please share this knowledge then, please.
  - jcranmer 4y ago
    It's easy to develop fault-free code: just redefine all those faults as (undocumented) features! That's not a helpful answer, but it's basically the same thing you're doing--redefining memory safety vulnerabilities that would be precluded entirely by writing in memory-safe languages as programmer faults.
  - tptacek 4y ago
    He's aware of a way to develop memory-corruption-fault free code, obviously.
- eesmith 4y ago
  As I recall, one of the advantages of C over Rust is that the SQLite authors have the tooling to do 100% branch coverage testing of the compiled binaries in C. They tried Rust, but Rust inserts code branches they are unable to test. The tradeoff then is the small number of bug causing the denial of service bugs listed, vs. not having 100% branch coverage. And they chose the latter. (The authors also believe Rust isn't portable enough, not handles out-of-memory errors well enough - https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a_safe_language_ https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a... .)
wglb 4y ago
The effort is massive and the experience to do so at scale is very rare.

midislack 4y ago

Stop this.

WesolyKubeczek 4y ago

Of course, let's better use a PostScript interpreter also written in C, so your exploits leveraging both at least look like art.

srvmshr 4y ago

When people write code which doesn't have memory safety & lacks the compactness needed for a mature product, it is not C language's fault C is a well tested compact language - the fact that Linux kernel, BSD kernels, device drivers and a whole lot of games and physics engines are written for performant systems is a testament to it's reliability. Additionally, I think it's the sane move. A language which is hot cake today (Yes, Rust) may or may not be in fashion 5 years from now when there's a new hotcake. Choices are made keeping 10-15 years project development in mind

pjmlp 4y ago
When Michael Abrash wrote his books, C compilers weren't known for the quality of their blazing machine code. It also has a proven record that no matter what, exploits are bound to happen, making the whole industry turn into hardware memory tagging as the ultimate solution to fix C.
- srvmshr 4y ago
  Memory exploits in Rust : Yes much less. That's where the world is (hopefully) headed to. But then a lot of people would disagree on "Lets jump on the <new-hot-language> bandwagon ASAP". Even the transition to parts of Linux kernel components in Rust is slow and cautious. In that sense, C is still a wide choice. Plus there are a lot of people actively working on C. Rust is only but picking up. it's more likely people will write buggy code on a new language than something which has been around for a while.
  - pjmlp 4y ago
    No need to bring Rust into this talk, Modula-2 from 1978 would already sort out most of C's mistakes, or even JOVIAL from 1958. C became a forced choice thanks to UNIX's free beer, and like JavaScript with the Web, it tainted us all.

deleted 4y ago

[deleted]