5 ms·
It disappoints me to see hardware compensate for the failures of software. We should have done better.
by e-dant 11mo ago
It disappoints me to see hardware compensate for the failures of software. We should have done better.
- Panzerschrek 11mo agoI agree. The underlying hardware should be as simple as needed and thus be cheap and consume little power. Fixing bad software practices (like using an unsafe language) via hardware hacks is a terrible mistake.
- amazingman 11mo agoOn the contrary, fixing pervasive and increasingly costly ecosystem issues in hardware is exactly the kind of innovation we need.
- thw_9a83c 11mo ago> Fixing bad software practices (like using an unsafe language) via hardware hacks is a terrible mistake. It's like saying airbags, seat belts (and other safety features) in cars are a terrible mistake because they just fix bad driving practices.
- amazingman 11mo agoHow could we have done better without first knowing better?
- pjmlp 11mo agoWe have know better for decades, that is why Multics has a higher security score than UNIX, C flaws versus PL/I are noted on DoD report.
- MangoToupe 11mo agoIt also helps that nobody uses multics, so nobody has bothered to exploit it
- pjmlp 11mo agoI can give other more recent examples, to prove the blindness of C community to security issues. From which decade since C came to be, do you wish the example?
- MangoToupe 11mo agoI'm certainly not defending C. I'm just saying multics is a horrible example.
- pjmlp 11mo agoIt is one out of many since 1958, starting with JOVIAL, how the industry has been aware of the security flaws that C allows for, which WG14 has very little interest in fixing, including turning down Dennis Ritchie proposal for fat pointers in 1990. Note that C authors were aware of many flaws, hence why in 1979 they designed lint, which C programmers were supposed to use as part of their workflow, and as mentioned above proposed fat pointers. Also note that C authors eventually moved on, first creating Alef (granted failed experiment), then on Inferno, Limbo, finalising with Go. Also Rust ideas are based on Cyclone, AT&T Research work on how to replace C. It was needed the tipping point of amount money spent fixing CVEs, ransomware, for companies and government to start thinking this is no longer tolerable.
- MangoToupe 11mo agoRust isn't going to fix security vulnerabilities, either, though. My point is focusing on the language is inherently missing the point, which is simply incorrect code.
- mk89 11mo agoYou have a whole class of dumb and dangerous bugs completely wiped off, which not even a new/junior untrusted developer can introduce. That's not nothing. Of course, not checking if a user has permissions to perform an operation is not something Rust or any language will protect you against, but come on it's almost 2026 and we still are talking about use after free...
- thw_9a83c 11mo ago> It disappoints me to see hardware compensate for the failures of software. We should have done better. I disagree. From a user's point of view, hardware-assisted memory safety is always beneficial. As a user of any software, you cannot verify that you are running a program that is free of memory access errors. This is true even when the software is written in Rust or an automatic memory-managed language. I hope that one day I will be able to enable memory integrity enforcement for all processes running on my computers and servers, even those that were not designed for it. I would rather see a crash than expose my machine to possible security vulnerabilities due to memory access bugs.
- MangoToupe 11mo agoI'm skeptical that you even can fully prevent exploitation of human error in software design. This just narrows one class of error.