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

31–40 of 71 posts

Re: The Arm64 memory tagging extension in Linux

#31

Post by rjsw »

cesaref wrote: post #29

Not sure if this has been mentioned, but this exact technique (storing extra data in addresses) was used in the early days of the MacOS, with 24 bits for the address, and 8 bits for extra info (not sure if I can remember exactly what they were for). The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM which was of course far more than would ever be in a computer... By the time the Mac…

The Mac IIci was the first 32 bit clean machine.

Plenty of dynamically typed languages have used the bottom bits in an address to store tags. You have two available on a 32 bit machine, three on 64 bit. The SPARCv7 has instructions that will do arithmetic on tagged values.

Re: The Arm64 memory tagging extension in Linux

#32

Post by rjsw »

Symmetry wrote: post #12
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.

It doesn't look like it to me.

I did propose storing type values in a TLB a long time ago but haven't run any simulations for it. Had started building some hardware to do type checking on an Atari ST but didn't finish it.

Re: The Arm64 memory tagging extension in Linux

#33

Post by bitwize »

londons_explore wrote: post #4

Random 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…

It seems that the tag mappings will need to live in separate physical RAM, so that info could be pulled from the tagmap RAM chips at the same time as the data is pulled from the data RAM chips.

Using multiple RAM chips to increase throughput is an old computer engineering technique; it was, for instance, the entire justification for planar graphics modes in early graphics hardware.

Re: The Arm64 memory tagging extension in Linux

#34

Post by bitwize »

tpxl wrote: post #27
five-robert wrote: post #16

Earlier quoted context omitted.

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

I am flirting with the idea of having 1TB of RAM on my servers as a small start-up. Having 256TB in 20 years seems reasonable.

You're gonna need at least that much to run the Electron apps of 20 years from now...

Re: The Arm64 memory tagging extension in Linux

#35

Post by crocktucker »

cesaref wrote: post #29

Not sure if this has been mentioned, but this exact technique (storing extra data in addresses) was used in the early days of the MacOS, with 24 bits for the address, and 8 bits for extra info (not sure if I can remember exactly what they were for). The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM which was of course far more than would ever be in a computer... By the time the Mac…

" ... if memory serves ... ", well done.

Re: The Arm64 memory tagging extension in Linux

#36

Post by Someone »

cesaref wrote: post #29

Not sure if this has been mentioned, but this exact technique (storing extra data in addresses) was used in the early days of the MacOS, with 24 bits for the address, and 8 bits for extra info (not sure if I can remember exactly what they were for). The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM which was of course far more than would ever be in a computer... By the time the Mac…

The extra bits stored flags that indicated whether handles were movable, could be purged at will, or came from a resource (on disk)

IIRC Excel went a bit further by using the leftover bits and even bit(s) starting at bit 24. That worked until hardware stopped wrapping around memory. Apple created a launch error “program had special memory requirements” which actually meant “this is Excel version so-and-so”.

And yes, that can bite you in the future, but the gains today can (appear to) outweigh that.

It also is perfectly valid when you control both the side that determines the constraints and the side that runs extremely close to them. For example, Cocoa’s tagged pointers (https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-bui...) are fine, given that Apple both controlled the memory allocator and the library assuming it aligned allocations (they also are safer in that they won’t try to read from addresses that don’t point to valid memory. That’s essential for their use)

Re: The Arm64 memory tagging extension in Linux

#37

Post by enedil »

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.

Comparing pointers not coming from the same allocation is undefined behaviour per C++ standard.

Re: The Arm64 memory tagging extension in Linux

#38

Post by Stierlitz »

cesaref wrote: post #29

Not sure if this has been mentioned, but this exact technique (storing extra data in addresses) was used in the early days of the MacOS, with 24 bits for the address, and 8 bits for extra info (not sure if I can remember exactly what they were for). The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM which was of course far more than would ever be in a computer... By the time the Mac…

> .. The 68000 only had 24 address lines after all. This allowed a maximum of 16Mb of RAM ..

And now we need 16GB to do exactly the same thing! Long ago I made my own DOS/Netscape image that ran from a 1MB 3 1/4 inch floppy that did the exact same thing! It booted and loaded a compressed ramdisk into memory and ran from there.

Re: The Arm64 memory tagging extension in Linux

#40

Post by saagarjha »

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.)
Post reply on HN