4 ms·

I wonder about the framing of the title here. Rust is great but realistically a lot of software with memory safety bugs doesn't need to be written in C in the f

I wonder about the framing of the title here. Rust is great but realistically a lot of software with memory safety bugs doesn't need to be written in C in the first place. For example Java has a perfectly serviceable TLS stack written entirely in a memory safe language. Although you could try to make OpenSSL memory safe by rewriting it in Rust - which realistically means yet another fork not many people use - you could also do the same thing by implementing the OpenSSL API on top of JSSE and Bouncy Castle. The GraalVM native image project allows you to export Java symbols as C APIs and to compile libraries to standalone native code, so this is technically feasible now. There's also some other approaches. GraalVM can also run many C/C++ programs in a way that makes them automatically memory safe, by JIT compiling LLVM bitcode and replacing allocation/free calls with garbage collected allocations. Pointer dereferences are also replaced with safe member accesses. It works as long as the C is fairly strictly C compliant and doesn't rely on undefined behavior. This functionality is unfortunately an enterprise feature but the core LLVM execution engine is open source, so if you're at the level of major upgrades to Rust you could also reimplement the memory safety aspect on top of the open source code. Then again you can compile the result down to a shared native library that doesn't rely on any external JVM. Don't get me wrong, I'm not saying don't improve Rust compile times. Faster Rust compiles would be great. I'm just pointing out that, well, it's not the only memory safe language in the world, and actually using a GC isn't a major problem these days for many real world tasks that are still done with C.

titzer 4y ago
There is Go, too.
nindalf 4y ago
> you could try to make OpenSSL memory safe by rewriting it in Rust Or just write a better crypto stack without the many legacy constraints holding OpenSSL back. Rustls (https://github.com/rustls/rustls https://github.com/rustls/rustls) does that. It has also been audited and found to be excellent - report (https://github.com/rustls/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). You're suggesting writing this stack in a GC language. That's possible, except most people looking for an OpenSSL solution probably won't be willing to take the hit of slower run time perf and possible GC pauses (even if these might be small in practice). Also, these are hypothetical for now. Rustls exists today.
- fidgewidge 4y ago
  OpenSSL was just an example. You could also use XML parsing or many other tasks. Point is that the code already exists - it's not hypothetical - and has done for a long time. It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch. There are also many other cases where apps could feasibly be replaced with code written in managed languages and then invoked from C or C++. Anything written in C/C++ can certainly tolerate pauses when calling into third party libraries because malloc/free can pause for long periods, libraries are allowed to do IO without even documenting that fact etc. I think it's fair to be concerned that rewrite-it-in-rust is becoming a myopic obsession for security people. That's one way to improve memory safety but by no means the only one. There are so many cases where you don't need to do that and you'll get results faster by not doing so, but it's not being considered for handwavy reasons.
  - nindalf 4y ago
    > It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch. I’d agree, if rustls wasn’t already written, audited and maintained. And there are other examples as well. The internationalisation libraries Icu4c and Icu4j exist, but the multi-language, cross-platform library Icu4x is written in Rust. Read the announcement post on the Unicode blog (http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1 http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1) - security is only one of the reasons they chose to write it in Rust. Binary size, memory usage, high performance. Also compiles to wasm. Your comment implies that people rewrite in Rust for security alone. But there are so many other benefits to doing so.
  - josephg 4y ago
    I think the thing you’re missing is that opensource people love rewriting libraries in their favourite languages. Especially something well defined, like tls or an xml parser. Rustls is a great example. You wont stop people making things like this. Nor should you - they’re doing it for fun! It’s much more fun to rewrite something in a new language than maintain bindings to some external language. You could wrap a Java library with a rust crate, but it would depend on Java and rust both being installed and sane on every operating system. Maintaining something like that would be painful. Users would constantly run into problems with Java not being installed correctly on macos, or an old version of Java on Debian breaking your crate in weird ways. It’s much more pleasant to just have a rust crate that runs everywhere rust runs, where all of the dependencies are installed with cargo.
duped 4y ago
That's not feasible for the millions of devices that don't have the resources for deploying GraalVM or GraalVM compiled native images. The other thing to consider is that in many applications, nearly every single bit of i/o will flow through a buffer and cryptographic function to encrypt/decrypt/validate it. This is the place where squeezing out every ounce of performance is critical. A JIT + GC might cost a lot more money than memory safety bugs + AOT optimized compilation.
- fidgewidge 4y ago
  Native images are AOT optimized and use way less RAM than a normal Java app on HotSpot does. And you can get competitive performance from them with PGO. Using a GC doesn't mean never reusing buffers, and Java has intrinsics for hardware accelerated cryptography for a long time. There's no reason performance has to be less, especially if you're willing to fund full time research projects to optimize it. The belief that performance is more important than everything else is exactly how we ended up with pervasive memory safety vulns to begin with. Rust doesn't make it free, as you pay in developer hours.
  - duped 4y ago
    How big are GraalVM native images?
uluyol 4y ago
A lot of software might not need to be implemented in C... but it is. Not just one piece either, but there's ecosystem effects at play too. Rust interops much better with C than most languages, including Java, and offers a smoother transition path to increased safety.
pornel 4y ago
Because that won't help with software that "needs" to be written in C or C++. This fallacy is why these languages are still in use. Time after time, designers of all the safer languages were deciding that GC makes everything so much easier, and it's perfectly fine for overwhelming majority of programs. This is correct and rational if the goal is to get many people use the language, but a total self-own if the goal is to replace C and C++ entirely. This dodging of the low-level memory management problem was consistently avoiding exactly the types of programs that people felt they had to use C or C++ for. The easy majority of programs that don't need C is already well served, but the tough cases that needed C were left uncontested. From Rust's first introduction: http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf > Go seems to be barking up a different tree? > Everyone is dodging the niche I'm interested in

titzer 4y ago

There is Go, too.

nindalf 4y ago

> you could try to make OpenSSL memory safe by rewriting it in Rust Or just write a better crypto stack without the many legacy constraints holding OpenSSL back. Rustls (https://github.com/rustls/rustls https://github.com/rustls/rustls) does that. It has also been audited and found to be excellent - report (https://github.com/rustls/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/rustls/rustls/blob/main/audit/TLS-01-repo...). You're suggesting writing this stack in a GC language. That's possible, except most people looking for an OpenSSL solution probably won't be willing to take the hit of slower run time perf and possible GC pauses (even if these might be small in practice). Also, these are hypothetical for now. Rustls exists today.

fidgewidge 4y ago
OpenSSL was just an example. You could also use XML parsing or many other tasks. Point is that the code already exists - it's not hypothetical - and has done for a long time. It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch. There are also many other cases where apps could feasibly be replaced with code written in managed languages and then invoked from C or C++. Anything written in C/C++ can certainly tolerate pauses when calling into third party libraries because malloc/free can pause for long periods, libraries are allowed to do IO without even documenting that fact etc. I think it's fair to be concerned that rewrite-it-in-rust is becoming a myopic obsession for security people. That's one way to improve memory safety but by no means the only one. There are so many cases where you don't need to do that and you'll get results faster by not doing so, but it's not being considered for handwavy reasons.
- nindalf 4y ago
  > It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch. I’d agree, if rustls wasn’t already written, audited and maintained. And there are other examples as well. The internationalisation libraries Icu4c and Icu4j exist, but the multi-language, cross-platform library Icu4x is written in Rust. Read the announcement post on the Unicode blog (http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1 http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1) - security is only one of the reasons they chose to write it in Rust. Binary size, memory usage, high performance. Also compiles to wasm. Your comment implies that people rewrite in Rust for security alone. But there are so many other benefits to doing so.
- josephg 4y ago
  I think the thing you’re missing is that opensource people love rewriting libraries in their favourite languages. Especially something well defined, like tls or an xml parser. Rustls is a great example. You wont stop people making things like this. Nor should you - they’re doing it for fun! It’s much more fun to rewrite something in a new language than maintain bindings to some external language. You could wrap a Java library with a rust crate, but it would depend on Java and rust both being installed and sane on every operating system. Maintaining something like that would be painful. Users would constantly run into problems with Java not being installed correctly on macos, or an old version of Java on Debian breaking your crate in weird ways. It’s much more pleasant to just have a rust crate that runs everywhere rust runs, where all of the dependencies are installed with cargo.

duped 4y ago

That's not feasible for the millions of devices that don't have the resources for deploying GraalVM or GraalVM compiled native images. The other thing to consider is that in many applications, nearly every single bit of i/o will flow through a buffer and cryptographic function to encrypt/decrypt/validate it. This is the place where squeezing out every ounce of performance is critical. A JIT + GC might cost a lot more money than memory safety bugs + AOT optimized compilation.

fidgewidge 4y ago
Native images are AOT optimized and use way less RAM than a normal Java app on HotSpot does. And you can get competitive performance from them with PGO. Using a GC doesn't mean never reusing buffers, and Java has intrinsics for hardware accelerated cryptography for a long time. There's no reason performance has to be less, especially if you're willing to fund full time research projects to optimize it. The belief that performance is more important than everything else is exactly how we ended up with pervasive memory safety vulns to begin with. Rust doesn't make it free, as you pay in developer hours.
- duped 4y ago
  How big are GraalVM native images?

uluyol 4y ago

A lot of software might not need to be implemented in C... but it is. Not just one piece either, but there's ecosystem effects at play too. Rust interops much better with C than most languages, including Java, and offers a smoother transition path to increased safety.

pornel 4y ago

Because that won't help with software that "needs" to be written in C or C++. This fallacy is why these languages are still in use. Time after time, designers of all the safer languages were deciding that GC makes everything so much easier, and it's perfectly fine for overwhelming majority of programs. This is correct and rational if the goal is to get many people use the language, but a total self-own if the goal is to replace C and C++ entirely. This dodging of the low-level memory management problem was consistently avoiding exactly the types of programs that people felt they had to use C or C++ for. The easy majority of programs that don't need C is already well served, but the tough cases that needed C were left uncontested. From Rust's first introduction: http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf > Go seems to be barking up a different tree? > Everyone is dodging the niche I'm interested in