[e-dant]

It disappoints me to see hardware compensate for the failures of software. We should have done better.

[thw_9a83c]

> 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]

I'm skeptical that you even can fully prevent exploitation of human error in software design. This just narrows one class of error.

[amazingman]

How could we have done better without first knowing better?

[pjmlp]

We 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.

[Panzerschrek]

I 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.

[thw_9a83c]

> 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]

On the contrary, fixing pervasive and increasingly costly ecosystem issues in hardware is exactly the kind of innovation we need.