The Arm64 memory tagging extension in Linux
1–10 of 71 posts
Re: The Arm64 memory tagging extension in Linux
#2How 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.
Re: The Arm64 memory tagging extension in Linux
#3Where are these keys stored? A 4 bit key for each 16 byte granule of memory in the system sounds substantial. Does the Linux kernel have to give the CPU a memory region to keep those mappings?
Re: The Arm64 memory tagging extension in Linux
#4Random read and write of a big memory region could now presumably cause double the number of DRAM accesses, and half the performance, since the tag mapping will need to be read in addition to the actual data. If the read of a memory address could have side effects (as is common with memory mapped hardware), does the hardware give guarantees that the tag will be checked before the memory is read or written? If so, that'll be an even bigger performance hit...
Re: The Arm64 memory tagging extension in Linux
#54 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...
Re: The Arm64 memory tagging extension in Linux
#6Where are these keys stored? A 4 bit key for each 16 byte granule of memory in the system sounds substantial. Does the Linux kernel have to give the CPU a memory region to keep those mappings?
The keys are stored in the bottom nibble of the top byte of pointers (I.e. bits 56-59)
Re: The Arm64 memory tagging extension in Linux
#7It'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...
Re: The Arm64 memory tagging extension in Linux
#8Random read and write of a big memory region could now presumably cause double the number of DRAM accesses, and half the performance, since the tag mapping will need to be read in addition to the actual data. If the read of a memory address could have side effects (as is common with memory mapped hardware), does the hardware give guarantees that the tag will be checked before the memory is read or written? If so, tha…
[deleted]
Re: The Arm64 memory tagging extension in Linux
#9Where are these keys stored? A 4 bit key for each 16 byte granule of memory in the system sounds substantial. Does the Linux kernel have to give the CPU a memory region to keep those mappings?
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...
Re: The Arm64 memory tagging extension in Linux
#10So 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?