In general, having this come to x86 is long-overdue and very welcome.
show comments
sparkie
Sparse on details.
Presumably will be based on the existing Linear Address Masking/Upper Address Ignore specs, which are equivalent, and will be similar to CHERI.
If so it needs to be opt-in or at least opt-out per process, because many language runtimes use these pointers bits to optimize dynamic types, and would suffer a big performance hit if they were unable to use them.
show comments
gpm
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.
show comments
Panzerschrek
It would be nice to know how this memory safety instructions should be used by software developers. Assuming I write C++ code, what should I do? Enable some new compiler flags? Use special runtime library? Use some special variant of the language standard library which uses these new instructions? Completely rewrite my code to make it safe?
fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.
show comments
akssri
The article seems sparse on details.
Would this imply an architecture similar to what Lisp-Machines once had ? That'd be a great addition IMO, and would speed up a lot of dynamic-ish languages without resorting to unsafe-routes for speed.
zdw
Now they just need to agree to implement ECC everywhere instead of using it as a product differentiator, so we can reduce the amount of random issues caused by memory and bus errors.
show comments
chmorgan_
Looks like this is in response to the Apple paper from a couple of weeks ago about memory tagging. Excellent news even if this wasn't pushed along by Apple.
muricula
Is there a whitepaper or ISA manual change describing the feature?
show comments
Uptrenda
They should standardize what's going on in Intel ME and AMD PSP (they won't since both are backdoors.)
pizlonator
It’s just probabilistic memory safety, at best
Still cool, but not a replacement for memory safety language implementations.
show comments
superkuh
I hope there are OS level (ie kernel build options) to turn this kind of thing off or just ignore the 'tags'. I know it's important for corporate use cases and monetary transactions and all that, but on my personal computer I use for fun I want to be able to peek and poke.
show comments
monocasa
[flagged]
show comments
casey2
Memory Saftey®
raverbashing
It's ok the C committee will make sure to fumble this up even with HW support
show comments
cogman10
Garbage article.
Like, cool, you guys are starting to talk about a new instruction set that will make C safe somehow. Yet you failed provide an ounce of detail for how you'll accomplish that.
This might as well been a "And we'll make our CPUs 10x faster and they'll use 10x less power!". Or "Future CPUs will have a 10ghz clock speed!"
Again, who is this article for? The government maybe to assure them that x86 will take cyber security seriously?
show comments
userbinator
To bring Corporate Authoritarianism to x86...
It's scary how much of the population will suddenly shut off their brains whenever "safety and security" or similar phrases are mentioned.
With all the negative comments here: This is existing technology on ARM64 (MTE) and on modern iPhones (https://security.apple.com/blog/memory-integrity-enforcement...).
For a good intuition why this (coupled with instrumenting all allocators accordingly) is a game-changer for exploitation, check https://docs.google.com/presentation/d/1V_4ZO9fFOO1PZQTNODu2...
In general, having this come to x86 is long-overdue and very welcome.
Sparse on details.
Presumably will be based on the existing Linear Address Masking/Upper Address Ignore specs, which are equivalent, and will be similar to CHERI.
If so it needs to be opt-in or at least opt-out per process, because many language runtimes use these pointers bits to optimize dynamic types, and would suffer a big performance hit if they were unable to use them.
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.
It would be nice to know how this memory safety instructions should be used by software developers. Assuming I write C++ code, what should I do? Enable some new compiler flags? Use special runtime library? Use some special variant of the language standard library which uses these new instructions? Completely rewrite my code to make it safe?
I wonder what happened that Apple/ARM has implemented something similar at nearly the same time. https://security.apple.com/blog/memory-integrity-enforcement...
Looking forward to this as x86 is the one lagging behind other CPUs on this matter, note that this is the second attempt, MPX did not went that well.
https://en.wikipedia.org/wiki/Intel_MPX
fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.
The article seems sparse on details.
Would this imply an architecture similar to what Lisp-Machines once had ? That'd be a great addition IMO, and would speed up a lot of dynamic-ish languages without resorting to unsafe-routes for speed.
Now they just need to agree to implement ECC everywhere instead of using it as a product differentiator, so we can reduce the amount of random issues caused by memory and bus errors.
Looks like this is in response to the Apple paper from a couple of weeks ago about memory tagging. Excellent news even if this wasn't pushed along by Apple.
Is there a whitepaper or ISA manual change describing the feature?
They should standardize what's going on in Intel ME and AMD PSP (they won't since both are backdoors.)
It’s just probabilistic memory safety, at best
Still cool, but not a replacement for memory safety language implementations.
I hope there are OS level (ie kernel build options) to turn this kind of thing off or just ignore the 'tags'. I know it's important for corporate use cases and monetary transactions and all that, but on my personal computer I use for fun I want to be able to peek and poke.
[flagged]
Memory Saftey®
It's ok the C committee will make sure to fumble this up even with HW support
Garbage article.
Like, cool, you guys are starting to talk about a new instruction set that will make C safe somehow. Yet you failed provide an ounce of detail for how you'll accomplish that.
This might as well been a "And we'll make our CPUs 10x faster and they'll use 10x less power!". Or "Future CPUs will have a 10ghz clock speed!"
Again, who is this article for? The government maybe to assure them that x86 will take cyber security seriously?
To bring Corporate Authoritarianism to x86...
It's scary how much of the population will suddenly shut off their brains whenever "safety and security" or similar phrases are mentioned.