8 ms·

> Accepting that it is extremely difficult to achieve complete memory safety with the performance level suitable for production deployment I don't think this i

by yholio 6y ago

> Accepting that it is extremely difficult to achieve complete memory safety with the performance level suitable for production deployment I don't think this is true anymore even for system code. As Rust demonstrates, fat pointers and apropriate compile time restrictions ensure memory and type safety with marginal performance overhead. It's simply not a problem to bother with anymore in the 21st century, if not for the immense legacy of unsafe C/C++ code and the inertia of the industry and people.

dig1 6y ago
I would not say this is a solved problem - Rust is too young in the industry; let's wait and see. Java claimed it solved all memory-related issues, and some even stated good security because the programs were executed in VM. Many years later, we saw you could make memory leaks in Java, and you can escape VM. There is no inertia here but an expected outcome. C/C++ programs are often predictable, memory issues are easy to catch, and tooling is top-notch. Good luck with other languages, except maybe with JVM/.NET platforms.
- MaxBarraclough 6y ago
  > C/C++ programs are often predictable, memory issues are easy to catch They are not. Memory-safety issues continue to impact major C/C++ codebases such as the Linux kernel and Chromium, sometimes manifesting as security vulnerabilities.
  - Alupis 6y ago
    I've been around long enough to know, given enough time, we'll find out Rust isn't the panacea to all our language problems - just like what the parent pointed out about Java and it's memory safety promises back in the day. It is indeed quite possible to write memory safe C/C++ code... and it's done every day. You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes. The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore! This leads to all kinds of problems as more people touch the code over many years and C++ standards. I'm very interested in seeing Rust mature in this space... if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has.
    - MaxBarraclough 6y ago
      > we'll find out Rust isn't the panacea to all our language problems I don't think anyone is suggesting it will be. It's not about to supplant Ada SPARK, for instance, as Rust is far behind in terms of formal analysis. > just like what the parent pointed out about Java and it's memory safety promises back in the day Java does address the memory-safety issues of C and C++. You can't have a buffer overflow vulnerability in pure Java code. You can't have any kind of undefined behaviour due to memory-management mistakes in your code. You can't double-free, or use-after-free, or deference a pointer to a local variable that has gone out of scope. You can't trigger undefined behaviour through a read-before-write bug in your code. It's possible to have a memory leak in Java, if you retain references to objects for too long, but that won't ever give rise to undefined behaviour. Of course, there can still be bugs in a JVM, but that's another matter. All languages are vulnerable to compiler bugs. Other languages like JavaScript do the same. It's possible to leak memory, but it's never possible to trigger undefined behaviour from JavaScript. That's a vital part of its security model. > It is indeed quite possible to write memory safe C/C++ code... and it's done every day That doesn't sound right. There's a reason I gave the examples of the Linux kernel and Chromium. They're written by highly competent developers, but they still have subtle memory-management bugs. Most C/C++ codebases are written by less competent developers, but are of far less interest to attackers, so it's of less consequence. Their memory-management bugs are likely to go unnoticed forever. I agree it's possible to write C/C++ code without memory-management bugs (there are various formal development systems for C), but it's a significant challenge. I'd hope avionics software, for instance, would be entirely free of such bugs. > You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes. They're not that rare, they're a major source of serious security vulnerabilities, and languages like Safe Rust can close the door on them entirely. > The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore! Agreed. C++ is quite a lumbering monster of complexity. Ada also has a reputation for being somewhat bloated, but it's not as far gone as C++. > if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has Keep an eye on Zig, too. Also D and Nim, and perhaps Vala. Also the lesser-known ZZ and Dafny languages, which look very interesting. https://github.com/aep/zz https://github.com/aep/zz https://github.com/dafny-lang/dafny https://github.com/dafny-lang/dafny
- Alupis 6y ago
  Not to mention binary size too. The same program written in Rust can be magnitudes larger in binary size[1], which is a complete non-starter for many embedded projects (where a lot of C/C++ code is destined to live). [1] https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna
  - qw3rty01 6y ago
    It's a bit unfair to use a default hello world program as an argument for why binaries are too large to use in an embedded context, because rust binaries can be made very small with tuning[1][2][3]. [1] https://www.codeslow.com/2019/12/tiny-windows-executable-in-rust.html https://www.codeslow.com/2019/12/tiny-windows-executable-in-... [2] https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust [3] https://rust-embedded.github.io/book/unsorted/speed-vs-size.html https://rust-embedded.github.io/book/unsorted/speed-vs-size....
  - zozbot234 6y ago
    See https://news.ycombinator.com/item?id=23496107 https://news.ycombinator.com/item?id=23496107 which links a number of rather detailed articles discussing Rust binary sizes.
  - dthul 6y ago
    It seems like this blog post is not very well thought out. At least the Rust version was compiled in debug mode, binaries were not stripped, the size-optimizing compiler profile was not used and neither was LTO. This repository contains information on how to achieve small Rust binaries: https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
    - saagarjha 6y ago
      Some of those are useful, many are absolutely awful from the viewpoint of leaving in debugability.
      - 6y ago
- staticassertion 6y ago
  I think it's worth noting that what you're referring to - the JVM escapes - are exploited under a completely different threat model where the attacker already has remote code execution. In this model the attacker already can execute code on the victim's host, but the VM attempts to limit what the attacker can do via restricted APIs. It's just a completely different threat.
Animats 6y ago
Yes. We really need a usable C to Rust translator. The existing "transpilers" just turn C with pointer arithmetic into Rust with pointer arithmetic. The output is awful.[1] This is a hard problem, but not impossible. There are people who say it's impossible. The usual excuses are obfuscated code, undecidablity, need to maintain binary compatibility, etc. Those are not show-stoppers. What's needed is something that converts C to ideomatic safe Rust most of the time, and to fat-pointer slow but safe Rust when the converter can't figure out what the code is doing. This is a job comparable to an optimizing compiler, and that's a big project. It will take money. More detailed comments on Rust forums: [2] Trying to patch up C is not promising. It's been tried, many times. The thesis shows most of the approaches that have been tried. GCC used to have a "fat pointer" option with checking, but it was rarely used, and has, I think, been deprecated. Putting extra info in the high bits of pointers has been tried. Memory allocation where all allocations in a block are the same size and you can look up the size of by block has been tried. Syntax changes to C have been proposed; I've been down that road. [1] https://c2rust.com/ https://c2rust.com/ [2] https://users.rust-lang.org/t/c-to-rust-translator/55381/14 https://users.rust-lang.org/t/c-to-rust-translator/55381/14
- moonchild 6y ago
  > Trying to patch up C is not promising. It's been tried, many times Isn't it? It looks like the author is cherry-picking approaches that haven't worked. Isabelle and verifast do very well at making c secure, for instance.
  - yholio 6y ago
    Patching up C has been attempted many times, with great success. Problem is, once the patch-up is completed, the language and memory layout of things like stacks, structures etc. that you end up with makes that secure language no longer C. You lose the ability to recompile billions of lines of legacy code, you lose binary compatibility and/or require compatibility and emulation layers or stupid "unsafe" modes that negate the benefit. What you end up with is a silly new language that inherits the awkward syntax of something designed in the 60s and lacks the rich expressivity and idioms of newer languages. At that point, it makes little sense to not start from scratch and work with a completely new language adequate for your application - such as Rust or Java.

by yholio 6y ago

dig1 6y ago

I would not say this is a solved problem - Rust is too young in the industry; let's wait and see. Java claimed it solved all memory-related issues, and some even stated good security because the programs were executed in VM. Many years later, we saw you could make memory leaks in Java, and you can escape VM. There is no inertia here but an expected outcome. C/C++ programs are often predictable, memory issues are easy to catch, and tooling is top-notch. Good luck with other languages, except maybe with JVM/.NET platforms.

MaxBarraclough 6y ago
> C/C++ programs are often predictable, memory issues are easy to catch They are not. Memory-safety issues continue to impact major C/C++ codebases such as the Linux kernel and Chromium, sometimes manifesting as security vulnerabilities.
- Alupis 6y ago
  I've been around long enough to know, given enough time, we'll find out Rust isn't the panacea to all our language problems - just like what the parent pointed out about Java and it's memory safety promises back in the day. It is indeed quite possible to write memory safe C/C++ code... and it's done every day. You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes. The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore! This leads to all kinds of problems as more people touch the code over many years and C++ standards. I'm very interested in seeing Rust mature in this space... if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has.
  - MaxBarraclough 6y ago
    > we'll find out Rust isn't the panacea to all our language problems I don't think anyone is suggesting it will be. It's not about to supplant Ada SPARK, for instance, as Rust is far behind in terms of formal analysis. > just like what the parent pointed out about Java and it's memory safety promises back in the day Java does address the memory-safety issues of C and C++. You can't have a buffer overflow vulnerability in pure Java code. You can't have any kind of undefined behaviour due to memory-management mistakes in your code. You can't double-free, or use-after-free, or deference a pointer to a local variable that has gone out of scope. You can't trigger undefined behaviour through a read-before-write bug in your code. It's possible to have a memory leak in Java, if you retain references to objects for too long, but that won't ever give rise to undefined behaviour. Of course, there can still be bugs in a JVM, but that's another matter. All languages are vulnerable to compiler bugs. Other languages like JavaScript do the same. It's possible to leak memory, but it's never possible to trigger undefined behaviour from JavaScript. That's a vital part of its security model. > It is indeed quite possible to write memory safe C/C++ code... and it's done every day That doesn't sound right. There's a reason I gave the examples of the Linux kernel and Chromium. They're written by highly competent developers, but they still have subtle memory-management bugs. Most C/C++ codebases are written by less competent developers, but are of far less interest to attackers, so it's of less consequence. Their memory-management bugs are likely to go unnoticed forever. I agree it's possible to write C/C++ code without memory-management bugs (there are various formal development systems for C), but it's a significant challenge. I'd hope avionics software, for instance, would be entirely free of such bugs. > You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes. They're not that rare, they're a major source of serious security vulnerabilities, and languages like Safe Rust can close the door on them entirely. > The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore! Agreed. C++ is quite a lumbering monster of complexity. Ada also has a reputation for being somewhat bloated, but it's not as far gone as C++. > if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has Keep an eye on Zig, too. Also D and Nim, and perhaps Vala. Also the lesser-known ZZ and Dafny languages, which look very interesting. https://github.com/aep/zz https://github.com/aep/zz https://github.com/dafny-lang/dafny https://github.com/dafny-lang/dafny
Alupis 6y ago
Not to mention binary size too. The same program written in Rust can be magnitudes larger in binary size[1], which is a complete non-starter for many embedded projects (where a lot of C/C++ code is destined to live). [1] https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna
- qw3rty01 6y ago
  It's a bit unfair to use a default hello world program as an argument for why binaries are too large to use in an embedded context, because rust binaries can be made very small with tuning[1][2][3]. [1] https://www.codeslow.com/2019/12/tiny-windows-executable-in-rust.html https://www.codeslow.com/2019/12/tiny-windows-executable-in-... [2] https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust [3] https://rust-embedded.github.io/book/unsorted/speed-vs-size.html https://rust-embedded.github.io/book/unsorted/speed-vs-size....
- zozbot234 6y ago
  See https://news.ycombinator.com/item?id=23496107 https://news.ycombinator.com/item?id=23496107 which links a number of rather detailed articles discussing Rust binary sizes.
- dthul 6y ago
  It seems like this blog post is not very well thought out. At least the Rust version was compiled in debug mode, binaries were not stripped, the size-optimizing compiler profile was not used and neither was LTO. This repository contains information on how to achieve small Rust binaries: https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust
  - saagarjha 6y ago
    Some of those are useful, many are absolutely awful from the viewpoint of leaving in debugability.
    - 6y ago
staticassertion 6y ago
I think it's worth noting that what you're referring to - the JVM escapes - are exploited under a completely different threat model where the attacker already has remote code execution. In this model the attacker already can execute code on the victim's host, but the VM attempts to limit what the attacker can do via restricted APIs. It's just a completely different threat.

Animats 6y ago

Yes. We really need a usable C to Rust translator. The existing "transpilers" just turn C with pointer arithmetic into Rust with pointer arithmetic. The output is awful.[1] This is a hard problem, but not impossible. There are people who say it's impossible. The usual excuses are obfuscated code, undecidablity, need to maintain binary compatibility, etc. Those are not show-stoppers. What's needed is something that converts C to ideomatic safe Rust most of the time, and to fat-pointer slow but safe Rust when the converter can't figure out what the code is doing. This is a job comparable to an optimizing compiler, and that's a big project. It will take money. More detailed comments on Rust forums: [2] Trying to patch up C is not promising. It's been tried, many times. The thesis shows most of the approaches that have been tried. GCC used to have a "fat pointer" option with checking, but it was rarely used, and has, I think, been deprecated. Putting extra info in the high bits of pointers has been tried. Memory allocation where all allocations in a block are the same size and you can look up the size of by block has been tried. Syntax changes to C have been proposed; I've been down that road. [1] https://c2rust.com/ https://c2rust.com/ [2] https://users.rust-lang.org/t/c-to-rust-translator/55381/14 https://users.rust-lang.org/t/c-to-rust-translator/55381/14

moonchild 6y ago
> Trying to patch up C is not promising. It's been tried, many times Isn't it? It looks like the author is cherry-picking approaches that haven't worked. Isabelle and verifast do very well at making c secure, for instance.
- yholio 6y ago
  Patching up C has been attempted many times, with great success. Problem is, once the patch-up is completed, the language and memory layout of things like stacks, structures etc. that you end up with makes that secure language no longer C. You lose the ability to recompile billions of lines of legacy code, you lose binary compatibility and/or require compatibility and emulation layers or stupid "unsafe" modes that negate the benefit. What you end up with is a silly new language that inherits the awkward syntax of something designed in the 60s and lacks the rich expressivity and idioms of newer languages. At that point, it makes little sense to not start from scratch and work with a completely new language adequate for your application - such as Rust or Java.