Intel Revs Its Linear Address Masking Patches For Linux

[Sergey Podobry]

What would be possible use cases for this? I vaguely remember something like this being present in i960mx ...

It's used by garbage collectors to mark pointers. Java can do that on ARM as ARM has address masking instructions for a long time. x86-64 was lacking this kind of instructions and Java maps the same heap memory to different addresses so it can flip high bits in a pointer and the pointer will remain valid and will point to the same object.

[OneTimeShot]

Reminds me of the old days when people used to stash stuff in the top 8 bits of 32bit addresses...

...a lot of software stopped working when 16Mb stopped being "a lot of memory"....

[sinepgib]

This would also be useful for generational references.

[archkde]

It depends. If the CPU actually ignore those bits when accessing the pointed item but really compare them in the CAS operation, then it behaves like a DCAS, since it's comparing X and Y at unrelated address, and you can fiddle with the bits in Y and X whatever you like. The operation is something like

X = X | some marker in high bits; Z = Y & high bits mask; DCAS(X, Y, Z, new value)

.

If instead it ignores the high bit in all instructions then it's a regular DWCAS as you said.
I don't know this technology so I can't say. We'll certainly see people use it through.

Well, it does really ignore the bits while addressing but includes them in the compare as you say (how would it not include the bits in the compare anyway, an address is just another number to the CPU in this situation). However, I still don't see how you get a DCAS here. If you use the non-canonical address for addressing, it's just a plain old CAS, and if you use it in the compare, you get a 16-bit+48-bit "DWCAS" if you so want (which is actually something you can already do by then masking the extra bits away in software before using the value for addressing again). At best I can see how you could implement a shitty approximation of LL/SC.

[carewolf]

Reminds me of the old days when people used to stash stuff in the top 8 bits of 32bit addresses...

...a lot of software stopped working when 16Mb stopped being "a lot of memory"....

Yeah, but unlike 32bit addressing we are not going to need 64bit of physically mapped memory in any realistic timeframe. The semiconductors for the RAM would be measured in galaxies of atoms. Plus existing CPUs already have some limits like ~48bits to addressable memory, leaving unused bits even the best of circumstances.

[lowflyer]

It's actually quite amusing to see that after the decades of "who cares about wasted gigabytes", it suddenly comes en vogue to "save" a few bits on each address register.

Undoubtedly there are useful applications. But likewise undoubtedly this paves the way for a whole new family of vulnerabilities - or shall I say "a whole new tribe". A very similar thing like the oh so praised branch prediction that came to haunt us not even a decade later.

[sinepgib]

It's actually quite amusing to see that after the decades of "who cares about wasted gigabytes", it suddenly comes en vogue to "save" a few bits on each address register.

It was always an idiotic take and CPU makers never listened to it, thankfully. It's also not just about the address registers, but about the cache. Proper usage cache is nowadays possibly the most critical part of performance.

[arQon]

There are all sorts of things you COULD do with this. However, ISTM at least 90% likely that the main use will be for (pre-)exploit protection, i.e. holding refcounts, or a few bits/hash of the call stack, etc; either at runtime or via valgrind / fuzzers / etc.

[sinepgib]

There are all sorts of things you COULD do with this. However, ISTM at least 90% likely that the main use will be for (pre-)exploit protection, i.e. holding refcounts, or a few bits/hash of the call stack, etc; either at runtime or via valgrind / fuzzers / etc.

There's also a (similar) use for storing typing information in the pointers, so a cast could check whether the pointer is actually of a type that can be converted into the target without anything other than some static table and the pointer itself.