MPX is slower and significantly more memory hungry than approaches to software bounds checking for C. That's the cost of ABI compatibility.
New ABI is an acceptable cost occasionally, but when done it needs to be done right. Screwing up & having to repeat is really bad image.
-
-
Fully agree. Prematurely pushing a new ABI or hard-wiring an approach in hardware is bad. Definitely shouldn't be done behind closed doors.
-
Can do that for entirely internal platforms but it's awful that ARM and Intel don't consult with the broader developer / academic community.
-
Going to end up with all kinds of weird weak, slow and broken mitigations hard-wired into hardware. Not a fan of that approach at all.
-
It's a lot different if it's only in software and not done in a way that encodes it as an API / ABI that needs to be supported forever.
-
Can't understand how throwing stuff at the wall to see what sticks is a sustainable approach to ISA design but what do we know.
-
Not a big fan of https://lwn.net/Articles/718888/ … either. Hardware should take a longer term approach than this, no?
-
I am biased here. This is exploring a new primitive. Prefer to see where this takes us rather than waiting for a long term perfect thing.
-
Hardware shouldn't even be involved. It's about grasping at ways to monopolize the cpu/isa market, not protecting users.
- 4 more replies
New conversation -
-
-
this is an area where VMs can have an advantage: the low-level ABI can be changed more readily than if using precompiled native code...
-
though, a weak area is the preference for many VMs to rely on GC's or be fairly specialized for specific HLLs (typically not C), ...
-
a "clever VM" might be one which AOT compiles everything in advance, but invalidates/recompiles apps/libs if the ABI changes or similar.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.