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

11–20 of 71 posts

Re: The Arm64 memory tagging extension in Linux

#11

Post by flohofwoe »

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...

Is this really still a problem with virtual memory management? The virtual address space size could be a property of the process (e.g. 48 bits vs the full 64 bits). The vast majority of applications today doesn't even need more than 32-bits of address space and could use the top 32-bits for something else if the memory mapping hardware ignores the unused bits).

Re: The Arm64 memory tagging extension in Linux

#12

Post by Symmetry »

jpcooper wrote: post #10

So a key is stored in the unused portion of memory pointers which should match the key associated to the memory it points to. I couldn’t figure out from the article where the key is stored in the corresponding memory. Can anyone explain?

I'd assume the key is stored in the hardware memory translation structures like the TLB.

Re: The Arm64 memory tagging extension in Linux

#13

Post by flohofwoe »

londons_explore wrote: post #2

How does this impact software that does memory pointer comparisons? Eg. Store pointers to all these objects into a std::set? The memory tag will now form part of the keys to this set, and would affect iteration order etc... It could cause breakage in existing applications.

Memory allocators are already returning more or less "random" pointers, so using pointers for sorting is already a bad idea. Even using pointers for equality-comparison isn't usually a good idea because the same memory location might be reused when the allocator recycles memory (those tags could actually help with making such "recycled" pointers unique over time).

Re: The Arm64 memory tagging extension in Linux

#14

Post by Liquid_Fire »

londons_explore wrote: post #9
dan-robertson wrote: post #6

Earlier quoted context omitted.

The keys are stored in the bottom nibble of the top byte of pointers (I.e. bits 56-59)

Yes, but they also need to be stored somewhere else for the CPU to compare them against something... Where else are they stored...

It's implementation defined (by the hardware). They could be stored in a reserved part of the RAM, or you could build special RAM that can store the extra bits alongside the data, or any other compatible solution.

Re: The Arm64 memory tagging extension in Linux

#15

Post by flohofwoe »

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...

IMHO it's less of a security feature, and more of a debugging aid (the overlap with security is when a failed check causes program termination). You might get more fine-grained overflow checks (vs guard pages), or dangling pointer checks (depending on how that key is stored, e.g. more than one key per memory page?).

It's faster then doing the same in code (e.g. via 'tagged handles': https://floooh.github.io/2018/06/17/handles-vs-pointers.html), or memory debugging tools like Valgrind or clang ASAN (and unlike Valgrind or ASAN, the checks are always enabled, also in the "release version").

Re: The Arm64 memory tagging extension in Linux

#16

Post by five-robert »

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?

Re: The Arm64 memory tagging extension in Linux

#17

Post by sherincall »

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...

The estimated number of atoms on earth is on the order of 1e50, which is 60 bits. If you take the 4 bits out of the 64bit address for tagging, you can still address individual atoms.

EDIT: My math is bad, see comments below.

I can unsarcastically say that no one will ever need full 64bit addresses on this planet.

Re: The Arm64 memory tagging extension in Linux

#18

Post by sherincall »

flohofwoe wrote: post #13
londons_explore wrote: post #2

How does this impact software that does memory pointer comparisons? Eg. Store pointers to all these objects into a std::set? The memory tag will now form part of the keys to this set, and would affect iteration order etc... It could cause breakage in existing applications.

Memory allocators are already returning more or less "random" pointers, so using pointers for sorting is already a bad idea. Even using pointers for equality-comparison isn't usually a good idea because the same memory location might be reused when the allocator recycles memory (those tags could actually help with making such "recycled" pointers unique over time).

Be that as it may, existing software that used to work will no longer work, and the developers might not be around/able to fix it.

There are also cases of custom suballocators or arrays of objects - Looking at an address makes it possibly to figure out which array it belongs to. This code would break.

Granted, it would still be possible to do all this if you just mask off the tag bits, but it requires a software change.

Re: The Arm64 memory tagging extension in Linux

#19

Post by five-robert »

sherincall wrote: post #17
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...

The estimated number of atoms on earth is on the order of 1e50, which is 60 bits. If you take the 4 bits out of the 64bit address for tagging, you can still address individual atoms. EDIT: My math is bad, see comments below. I can unsarcastically say that no one will ever need full 64bit addresses on this planet.

2^66 bits - estimated storage space at Google data warehouse as of 2013 [0]

2^71 bits - total hard drive capacity shipped in 2016 [0]

I doubt your calculations.

[0] https://en.wikipedia.org/wiki/Orders_of_magnitude_(data)

Re: The Arm64 memory tagging extension in Linux

#20

Post by pm215 »

jpcooper wrote: post #10

So a key is stored in the unused portion of memory pointers which should match the key associated to the memory it points to. I couldn’t figure out from the article where the key is stored in the corresponding memory. Can anyone explain?

mwsealey's comment on the LWN article (in response to somebody asking that question there) has a good explanation of it. Basically exactly where the keys are stored is up to the implementation, but one reasonable implementation is for the memory controller to put them in the top part of the system DRAM (which is then not made available as 'normal' RAM). Architecturally the allocation tag space is entirely separate from system memory, though, and the only way to get at it is with the provided instructions for reading/writing tags, so any particular implementation can put any kind of storage it likes underneath. (A software model, for instance, might just allocate a separate lump of host RAM for storing the tags. QEMU's MTE emulation does that.)
Post reply on HN