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

51–60 of 71 posts

Re: The Arm64 memory tagging extension in Linux

#51

Post by Matt3o12_ »

jackewiehose wrote: post #49
flohofwoe wrote: post #44

Earlier quoted context omitted.

> uniqueness of pointers... What I mean is for example: you get a pointer by allocating memory, then free that memory, then you allocate again and get a pointer to the same memory location. Without a tag those two pointers would be equal, even though they come from separate memory allocations. This can be a source of bugs if the pointer is also used as some sort of object id, and I know that at least I stumbled over…

You can use the pointer as an object id, but only for living objects. The pointer becomes invalid the moment the memory is freed. Your bug was that you used an invalid pointer.

But doesn't this feature exactly help with this bug? Two memory allocations should now return different pointers (because the MTE nibble is different) therefore the comparision should fail. Unless ofcourse the application was using this undefined behavior (which would be very buggy since malloc can randomly refuse to reuse the same address even though it was freed and therefore create extremely hard and difficult to track bugs).

Re: The Arm64 memory tagging extension in Linux

#52

Post by StillBored »

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?")

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 VA's is going to get beyond the end of my career but someone will have to deal with it in the future. So its a little slower than 1 bit a year, but everyone is adding a few more bits (52/56/etc) because there are actual commercial computer systems with a few tens of TB of ram today. If persistent memory ever becomes a thing, someone _WILL_ want to mmap their multi PB storage cluster, and then there will be a scramble for more address bits.

Re: The Arm64 memory tagging extension in Linux

#53

Post by flohofwoe »

jackewiehose wrote: post #49
flohofwoe wrote: post #44

Earlier quoted context omitted.

> uniqueness of pointers... What I mean is for example: you get a pointer by allocating memory, then free that memory, then you allocate again and get a pointer to the same memory location. Without a tag those two pointers would be equal, even though they come from separate memory allocations. This can be a source of bugs if the pointer is also used as some sort of object id, and I know that at least I stumbled over…

You can use the pointer as an object id, but only for living objects. The pointer becomes invalid the moment the memory is freed. Your bug was that you used an invalid pointer.

> Your bug was that you used an invalid pointer.

Exactly, but just declaring that a pointer is "invalid" doesn't help much with debugging such dangling pointer problems, while tagged pointers do.

It's not like an "invalid pointer" is any different from a "valid pointer" when you look at it. With the extra tag bits, an invalid pointer can actually be identified as such.

Re: The Arm64 memory tagging extension in Linux

#54

Post by StillBored »

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.

The couple year old power9 E980, can take 64T of ram. So there are people who have problems that need lots of addressable memory today.

Even so, it wouldn't be that hard to actually build a system that could in theory try and map 4PB of storage via mmap today, its about 1/2 a rack of fairly common equipment. Given there are various companies selling 50T ssd (https://www.anandtech.com/show/11639/viking-ships-uhcsilo-ss...) its probably possible to do it in under 10U.

Re: The Arm64 memory tagging extension in Linux

#55

Post by fulafel »

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?")

No, like on most other archs, people use tagged pointers in lisp and other runtimes on amd64 all the time. But the machine (like most ISAs) doesn't ignore any bits so you have to clear the tag bits before dereferencing.

You may be thinking of the fact that a full 64 bit VA space isn't supported in current implementations. But this has no impact on use of tagging compared to most other archs.

Re: The Arm64 memory tagging extension in Linux

#56

Post by guenthert »

StillBored wrote: post #52
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?")

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.

Re: The Arm64 memory tagging extension in Linux

#57

Post by [deleted] »

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?

[deleted]

Re: The Arm64 memory tagging extension in Linux

#58

Post by kjs3 »

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…

While conceptually similar (and made me think of the same thing), this doesn't really look like the same thing. In the Mac case, it was (ab)using technically unused addressed bits in unintended ways. In the ARM case, it is an explicit architectural feature. More like pointer tags in Lisp machines.

Re: The Arm64 memory tagging extension in Linux

#59

Post by Retr0spectrum »

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…

You're overlooking a) existing page table lookup overhead b) hierarchical caching.

Re: The Arm64 memory tagging extension in Linux

#60

Post by rbanffy »

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.

A 128-bit CPU is not something I'd find outlandish in 20 years. OTOH, I was reading my e-mail on a 64-bit workstation (largely by accident, but still).

In any case, I'd be quite surprised to see a 64-bit CPU doing such heavy lifting in 2040.

Post reply on HN