4 ms·

It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level s

by gpm 1y ago

It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.

hedora 1y ago
Rust code that uses unsafe still needs this sort of protection.
- gpm 1y ago
  "Needs" is a strong word, would benefit from a bit, but in practice I think the number of vulnerabilities rust code typically has is not large enough to justify the expense of compromising the performance of every CPU ever sold (thus requiring more, consuming more energy, etc). There's also been steady progress towards creating systems to prove unsafe rust correct - at which point it wouldn't even benefit from this. For example see the work amazon has been sponsoring to prove the standard library correct: https://github.com/model-checking/verify-rust-std/ https://github.com/model-checking/verify-rust-std/
  - vlovich123 1y ago
    A good chunk of Rust code often ends up linking in a C/C++ library where it’s still a concern (and this is ignoring that unsafe Rust is actually harder and more unsafe than C currently). More importantly there’s millions if not billions of existing lines of C/C++ not least of which is the VMs for “memory safe” languages like Java. There’s huge value add in automatically adding security for a fractional CPU cost since the world won’t be rewritten into Rust anytime soon.
a-dub 1y ago
it's like the end scene in fight club. except instead of credit card company office towers it's the borrow checker and associated skyscrapers that symbolize the ascent of rust that are going down in flames as the x86 antiheroes high five and the pixies start crooning "where is my mind" to rolling credits over the burning cityscape.
musicale 1y ago
> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C, for better or worse.
- thayne 1y ago
  AFAIK, most of windows and OSX (and iOS) are in memory unsafe languages as well (c, c++, and objective c)
  - musicale 1y ago
    macOS is (a) Unix (officially even!) and inherits many of its features and issues. To Apple's credit though they seem to be using a memory-safe language (Swift) for new code and libraries (at least at user level) and may be rewriting old code as well, and they have also added MIE/EMTE to Apple Silicon. They also ship clang/clang++ with support for -fbounds-safety and -fsanitize=address. Objective-C also supports Automatic Reference Counting, which helps with memory management. (Apple also implemented a garbage collector for Objective-C 2.0, but abandoned it in favor of ARC. I am aware that reference counting is technically a form of garbage collection.)
    - pjmlp 1y ago
      The reason being, as can be seen on the archives, the conservative tracing GC had several gotchas to work with existing code, thus segfaults were common. The way ARC works in Objective-C, by automating retain/release call patterns already required by existing frameworks was much safer to implement, without such crashes. Similar to all those C++ smart pointers automating COM reference counting.
  - pjmlp 1y ago
    Still, the keyword is still. Hence why Objective-C got GC, after its failure to play well with C semantics, got replaced with ARC, and afterwards Swift came to be. Microsoft now has a new policy in place, via the Secure Future Initiative, that only exiting code bases should be kept in C and C++, all new projects are to either use managed languages or Rust.
pjmlp 1y ago
We have had it before C was even invented, Burroughs nowadays still sold as Unisys ClearPath MCP was written in ESPOL, latter NEWP, with zero Assembly. The compiler provides intrisics, has bounds checking for strings and arrays. PL/I and its variants were also used across several systems, as were ALGOL dialects. Note C.A.R Hoare Turing award speech in 1980, "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." The "1980 language designers and users have not learned this lesson" is meant to be C without explicit refering to it.
gpderetta 1y ago
There are hundreds of billions of lines of code of critical software[1] written in unsafe languages, that is not going to be rewritten any time soon. Adding memory safety "for free" to such software is a net positive. Current CPUs are limited by power, transistors are essentially free. [1] often the VMs of safer higher level languages, in fact.
pron 1y ago
> we are finally getting low level software that no longer needs it We're not, though. There's a little bit of low-level software being written in Rust (and even that requires a non-trivial amount of unsafe code), but most new low-level software is being written in C++ or C. And even if a more popular safe low-level programming language arrived tomorrow and gained a more respectable adoption, that still wouldn't be fast enough because of all the existing software.

by gpm 1y ago

hedora 1y ago

Rust code that uses unsafe still needs this sort of protection.

gpm 1y ago
"Needs" is a strong word, would benefit from a bit, but in practice I think the number of vulnerabilities rust code typically has is not large enough to justify the expense of compromising the performance of every CPU ever sold (thus requiring more, consuming more energy, etc). There's also been steady progress towards creating systems to prove unsafe rust correct - at which point it wouldn't even benefit from this. For example see the work amazon has been sponsoring to prove the standard library correct: https://github.com/model-checking/verify-rust-std/ https://github.com/model-checking/verify-rust-std/
- vlovich123 1y ago
  A good chunk of Rust code often ends up linking in a C/C++ library where it’s still a concern (and this is ignoring that unsafe Rust is actually harder and more unsafe than C currently). More importantly there’s millions if not billions of existing lines of C/C++ not least of which is the VMs for “memory safe” languages like Java. There’s huge value add in automatically adding security for a fractional CPU cost since the world won’t be rewritten into Rust anytime soon.

a-dub 1y ago

it's like the end scene in fight club. except instead of credit card company office towers it's the borrow checker and associated skyscrapers that symbolize the ascent of rust that are going down in flames as the x86 antiheroes high five and the pixies start crooning "where is my mind" to rolling credits over the burning cityscape.

musicale 1y ago

> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C, for better or worse.

thayne 1y ago
AFAIK, most of windows and OSX (and iOS) are in memory unsafe languages as well (c, c++, and objective c)
- musicale 1y ago
  macOS is (a) Unix (officially even!) and inherits many of its features and issues. To Apple's credit though they seem to be using a memory-safe language (Swift) for new code and libraries (at least at user level) and may be rewriting old code as well, and they have also added MIE/EMTE to Apple Silicon. They also ship clang/clang++ with support for -fbounds-safety and -fsanitize=address. Objective-C also supports Automatic Reference Counting, which helps with memory management. (Apple also implemented a garbage collector for Objective-C 2.0, but abandoned it in favor of ARC. I am aware that reference counting is technically a form of garbage collection.)
  - pjmlp 1y ago
    The reason being, as can be seen on the archives, the conservative tracing GC had several gotchas to work with existing code, thus segfaults were common. The way ARC works in Objective-C, by automating retain/release call patterns already required by existing frameworks was much safer to implement, without such crashes. Similar to all those C++ smart pointers automating COM reference counting.
- pjmlp 1y ago
  Still, the keyword is still. Hence why Objective-C got GC, after its failure to play well with C semantics, got replaced with ARC, and afterwards Swift came to be. Microsoft now has a new policy in place, via the Secure Future Initiative, that only exiting code bases should be kept in C and C++, all new projects are to either use managed languages or Rust.

pjmlp 1y ago

We have had it before C was even invented, Burroughs nowadays still sold as Unisys ClearPath MCP was written in ESPOL, latter NEWP, with zero Assembly. The compiler provides intrisics, has bounds checking for strings and arrays. PL/I and its variants were also used across several systems, as were ALGOL dialects. Note C.A.R Hoare Turing award speech in 1980, "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." The "1980 language designers and users have not learned this lesson" is meant to be C without explicit refering to it.

gpderetta 1y ago

There are hundreds of billions of lines of code of critical software[1] written in unsafe languages, that is not going to be rewritten any time soon. Adding memory safety "for free" to such software is a net positive. Current CPUs are limited by power, transistors are essentially free. [1] often the VMs of safer higher level languages, in fact.

pron 1y ago

> we are finally getting low level software that no longer needs it We're not, though. There's a little bit of low-level software being written in Rust (and even that requires a non-trivial amount of unsafe code), but most new low-level software is being written in C++ or C. And even if a more popular safe low-level programming language arrived tomorrow and gained a more respectable adoption, that still wouldn't be fast enough because of all the existing software.