Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Arm64 memory tagging extension in Linux

lwn.net

Post reply on HN
Print view View original

61–70 of 71 posts

Re: The Arm64 memory tagging extension in Linux

#61

Post by monocasa »

guenthert wrote: post #56
StillBored wrote: post #52

Earlier quoted context omitted.

And common javascript engines. Turns out a lot of interpreters hide bits away in what they precieve to be unused address bits. Its one of those lessons that everyone seems to be constantly relearning. Address spaces grow. One of my first "real" jobs, when this topic came up a very senior person said something to the effect. We continue to find ways to use up one of those bits roughly every year. Moving from 32-64 bit…

Value tagging may (and often does) use the lower bits to distinguish pointers from other values (integer, boolean, character, etc.) as objects are memory aligned. In those schemes the growth of the address space doesn't matter.

You can use the upper bits too. It's fairly common to use the top bit to discriminate between a pointer or an integer, since you can just test if the value is negative, which can be free on some architectures.

Re: The Arm64 memory tagging extension in Linux

#62

Post by guenthert »

ljhsiung wrote: post #47
nnx wrote: post #28

Earlier quoted context omitted.

Note this is for the virtual address space, not only for actual physical RAM. Having 256TB mmap’ed (to another kind of storage) does not seems totally out of reach.

True, but also note that a 52b mode (i.e. 12 bit tag) is also supported. I can't imagine anyone needing more than 4PB in the next 30 years, and the security gains now is (in my opinion) worth the potential refactoring in 30+ years that would be required.

Hmmh? A few years ago there were already a few sites with more than a PiB of storage total. I don't know of any which used some virtual memory or single address space scheme to access those, but I wouldn't want to rule it out.

Re: The Arm64 memory tagging extension in Linux

#63

Post by jcranmer »

five-robert wrote: post #16
londons_explore wrote: post #7

It's a shame we're using the top of pointers for other data... It's almost as if we didn't learn from the "3gb memory hole", the "gate a20 memory limit", and countless other times when using special address bits came back to bite system designers as RAM got bigger...

2^48 == 256TB. Anyone needs more than 256 Terabytes of RAM?

It's 256TiB of virtual address space. If you include NVMe drives memory-mapped into the address space, hitting that cap is not entirely unreasonable.

Intel added support for 5-level page tables (bumping virtual memory to 2^57 bytes) a few years ago: https://en.wikipedia.org/wiki/Intel_5-level_paging.

Re: The Arm64 memory tagging extension in Linux

#64

Post by cmarinas »

saagarjha wrote: post #40
swills wrote: post #39

Is this related to the CHERI stuff? https://vimeo.com/366246134 https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

It’s similar, but CHERI provides much stronger guarantees. (The ARM implementation will use 128-bit pointers, with the top half being used to store much more granular keys.)

CHERI provides spatial protection and is very strong at this but does not handle temporal protection well (use-after-free for example). Once a pointer is given to another code entity/compartment it is hard to revoke the permission since that's tied to the (capability) pointer itself, not the memory it points to. There are workarounds but not that nice.

MTE, OTOH, was specifically designed for detecting temporal bugs. For example, a freed object has the allocation tag (stored in memory) changed by the heap allocator so that the original pointer (with the original tag) can no longer access it. Of course, the trade-off is the 4 bits per 16-byte granule that need to be stored somewhere and the probabilistic nature (1 in 16 chance of hitting it).

But I think CHERI and MTE would complement each other nicely.

Re: The Arm64 memory tagging extension in Linux

#65

Post by staticassertion »

colejohnson66 wrote: post #45
znpy wrote: post #43

isn't like, memory tagging explicitly forbidden in x86-64 ? iirc it was used in lisp compilers/interpreters to speed up object unboxing (as in answering the question: "what class does the object pointed by this pointer belong to?")

Correct. x86-64 mandates “canonical” addresses where all the upper bits must be the same in order to dereference a pointer.[0] So on a processor with 48 physical address lines, the upper 16 must be either all set or all unset. This is obviously to prevent people using those upper bits to store extra data. Of course, this doesn’t stop you from being able to[a], it just makes it harder. [a]: The processor doesn’t know…

> But that’s a lot of work to save a byte or two.

Is it? It's something like two xors on a register. If that's a byte or two per pointer (ie: it's pointer metadata that you'd have to store anyway, which I assume is the use case) that's actually a pretty significant win, and could help reduce cache pressure, thereby buying you back the performance (and then some).

Addresses are also XOR'd all the time with a secret as a mitigation, I don't know that there's much of an impact at all.

Re: The Arm64 memory tagging extension in Linux

#66

Post by shard »

Here is a Google engineer explaining how memory tagging extension works in more detail in a white paper. According to the paper, about 2/3 of all CVEs are memory safety bugs, and memory tagging will help with catching undiscovered ones.

https://www.usenix.org/system/files/login/articles/login_sum...

Re: The Arm64 memory tagging extension in Linux

#67

Post by robocat »

londons_explore wrote: post #5

4 bit keys seems a bit limiting... I could imagine lots of scenarios where a 1 in 16 chance of an exploit succeeding is still a big issue...

In the most extremely sensitive environments:

1. It still helps with defence in depth

2. The threat of detection prevents attackers that need 100% stealth

3. Failures are likely to be detected which is still valuable as you can now mitigate damage

4. Failures are likely to be detected which helps get software faults fixed - which allows the ecology of security to improve over time

Re: The Arm64 memory tagging extension in Linux

#70

Post by pjmlp »

shard wrote: post #66

Here is a Google engineer explaining how memory tagging extension works in more detail in a white paper. According to the paper, about 2/3 of all CVEs are memory safety bugs, and memory tagging will help with catching undiscovered ones. https://www.usenix.org/system/files/login/articles/login_sum...

It does, as proven by Solaris on SPARC ADI, a similar technic with almost one decade of use by now.
Post reply on HN