Hacker News Reader

Comment by checker659 | Hacker News Reader

I never understood why software has to pay for the lack of memory safety primitives in the hardware.

People have tried, and so far, achieving safety through trusted compilers and (fairly complicated) run-time support has been much more efficient. A small team could probably design a RISC-V CPU with extensions for hardware-assisted bounds checking and garbage collection, but any real CPU that they can built would likely have performance levels that are typical for research-oriented RISC-V CPUs. Doing the same thing in software on a contemporary commercially established CPU is going to be much, much faster.

See that's the problem. Unless this is government mandated, no sane vendor is going to pay for the performance penalty.

> Doing the same thing in software on a contemporary commercially established CPU is going to be much, much faster.

In what sense? Do you know if there's been proper research done in this area? Surely implementing the bounds checking / permissions would be faster in hardware.

I'm worried that if memory tagging becomes mandatory, it sucks the air out of the room for solutions that might have a more long-lasting impact. Keep in mind that memory tagging is just heuristics beyond very specific bug scenarios (linear buffer overflows are the prime example). The whole thing does not seem fundamentally resistant to future adaptions of exploitation techniques. (Although oddly enough, I have been working on memory tagging lately.)

Regarding performant implementations of capability architectures, Fil-C running on modern CPUs is eventually going to overtake Arm's Morello reference board because it doesn't look like there's going to be a successor to the board. Morello was based on Arm's Neoverse-N1 core and produced using TSMC's N7 process. It was a research project, but it's really an outlier because such projects hardly ever have access to these kinds of resources (both CPU IP and tape-out on a previous-generation process). It seems all other implementations of CHERI are FPGA-based.

Can you say what hardware could do better? I.e. which kind of primitives do you miss, or would make it easier to develop safer software?

CHERI, but that's just one example.

Bounds checking of pointers, C Machine kind of.

Solaris and Linux SPARC since 2015, for example.

https://docs.oracle.com/en/operating-systems/solaris/oracle-...

https://docs.kernel.org/arch/sparc/adi.html

ARM MTE, as another one,

https://learn.arm.com/learning-paths/mobile-graphics-and-gam...

These approaches can only detect linear overflows deterministically. Use-after-frees (temporal safety violations) are only detected with some probability. It's mostly a debugging tool. And MTE requires special firmware, which is usually not available in the cloud because the tag memory reservation is a boot-time decision.

Still better than status quo on most systems.

It is kind of interesting how all attempts to improve security are akin to arguing about usefulness of seatbelts when people still die wearing them.

Reply on news.ycombinator.com