Memory tagging in hardware? Yay, they're implementing 1970s Lisp Machines again!
Memory Tagging and how it improves C/C++ memory safety
31–40 of 41 posts
Re: Memory Tagging and how it improves C/C++ memory safety
#32A long time ago I found some memory problems in a C++ codebase we had inherited and that crashes from time. In Windows you can protect memory blocks with a function call so I overloaded new and malloc and added some protected blocks before and after the actual memory. Then we ran the code for a lot and it would fault right at the point of the memory overwrite instead of some place later. It made the code very slow bu…
The Windows system heaps include a similar feature called PageHeap. You can enabled it for any process using Microsoft's pageheap.exe utility. It uses a lot of extra (virtual) memory and doesn't work well for applications that have their own memory sub-allocator like jemalloc or dlmalloc.
https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
Re: Memory Tagging and how it improves C/C++ memory safety
#33This somewhat reminds me of the Microsoft debugger convention of initializing memory with various tags so that when you crash with a pointer bug, you can tell what kind of memory was trod upon. They even made the hex codes semi-mnemonic so it was easier to remember, e.g., 0xCD=clean, 0xDD=dead, 0xFD=fence, etc. https://stackoverflow.com/a/370362/1424242 Interesting note that with this method in the paper, "Temporal a…
Wikipedia has a long list of magic debug numbers used by different tools and operating systems:
https://en.wikipedia.org/wiki/Magic_number_(programming)#Mag...
Re: Memory Tagging and how it improves C/C++ memory safety
#34A long time ago I found some memory problems in a C++ codebase we had inherited and that crashes from time. In Windows you can protect memory blocks with a function call so I overloaded new and malloc and added some protected blocks before and after the actual memory. Then we ran the code for a lot and it would fault right at the point of the memory overwrite instead of some place later. It made the code very slow bu…
This approach was implemented in Bruce Perens' "Electric Fence" library [1987].
https://en.wikipedia.org/wiki/Electric_Fence
I think he might have developed that while at Pixar.
Re: Memory Tagging and how it improves C/C++ memory safety
#35A long time ago I found some memory problems in a C++ codebase we had inherited and that crashes from time. In Windows you can protect memory blocks with a function call so I overloaded new and malloc and added some protected blocks before and after the actual memory. Then we ran the code for a lot and it would fault right at the point of the memory overwrite instead of some place later. It made the code very slow bu…
On illumos you can use libumem to replace malloc() via LD_PRELOAD, and then you can instruct it to do the same thing via the UMEM_DEBUG environment variable. It's a fantastic technique for catching these issues without completely destroying application performance. See also: https://illumos.org/man/umem_debug
Best BOFH comment this week!
Instead of suggesting modern tooling such as address sanitizer, poster suggest switching development to obscure unix os.
Poster profile even lists them working with loads of operating systems, this one included.
And still they debug memory errors like it's 1963.
Priceless!
Re: Memory Tagging and how it improves C/C++ memory safety
#36There is no such language as "C/C++".
Putting that in your title telegraphs that you don't have much to say, even if you might.
Re: Memory Tagging and how it improves C/C++ memory safety
#37Earlier quoted context omitted.
> Yes, the memory->tag mapping has to be stored somewhere, but that's true even for a segmented system, right? You need some place to store the segment offset and length: either some dedicated registers if you only allow a few of them, or some in-memory tables for more general schemes, right? Not if your segments/tags are static and defined beforehand, which is what I thought that were going for (Since that doesn't r…
> This is exactly what I'm thinking as well. If the platform has paging support, in theory this is cheaper then it seems because (besides using up tons of virtual memory) the array can be sparsely allocated, with only the regions actually in used taking up physical memory. Yes exactly. The worse case still seems like a doubling of (actual) memory use though: imagine a very sparsely accessed region of memory: even tod…
> Yes exactly. The worse case still seems like a doubling of (actual) memory use though: imagine a very sparsely accessed region of memory: even today each access would bring in a whole 4K page (on x86, for example), but now you'd bring in a whole 4K shadow page as well (yes, the access has to be really sparse to get this 1:1 ratio).
In theory you should be partially saved by the allocator, just because it is going to try and place as much stuff as it can into every page it allocates, as well as allocate multiple pages at once (So they all end-up in a row). An allocator that was aware of the 'shadow' pages should be able to allocate chunks of pages at once that correspond to a single 'shadow' page, ensuring you avoid creating tons of them. The higher alignment requirements mean more wasted memory though, meaning you need to allocate more pages and need then need more 'shadow' pages overall.
The paper suggests anywhere between 14% and 18% RAM overhead (discounting Android apps, which had a range from 6% to 42%) for 64 byte granularity, and that it actually goes down if you choose a smaller granularity like 16, due to the lower alignment requirement.
And of course, you're also talking about doubling memory accesses as well, assuming this is done in software. Every access has to first check the 'shadow' page. Unfortunately both of their implementations are at least partially hardware assisted, so I'm not sure you can use those numbers to just a pure CPU implementation, but they suggest around a 2x slowdown.
> I think a 4K granularity is next to useless - you already get that from the hardware/OS paging support. If you want to detect problems on a 4K level, you only need to change your allocator to mmap in a page at a time, which you can even already do on some with tunable ones.
I would agree. The tagging system can prevent a higher percentage of OOB accesses at the page level in theory, but considering the size of the address-space vs the number of allocations (assuming a 64-bit/48-bit address space) I think the likelihood of an OOB access actually hitting another separate allocation (assuming a mostly random placement) is already pretty low, so the tagging system would make it lower (You now have to hit a random allocation with the correct tag) but not significantly lower then before, and at the cost of performance.
Re: Memory Tagging and how it improves C/C++ memory safety
#38A long time ago I found some memory problems in a C++ codebase we had inherited and that crashes from time. In Windows you can protect memory blocks with a function call so I overloaded new and malloc and added some protected blocks before and after the actual memory. Then we ran the code for a lot and it would fault right at the point of the memory overwrite instead of some place later. It made the code very slow bu…
We did the same thing for some device driver code and also use a tool called "Boundschecker", back in the 90s. I just checked and it still exists!
We also had BoundsChecker but it was my little library that found most bugs eventually :)
Re: Memory Tagging and how it improves C/C++ memory safety
#39Memory tagging in hardware? Yay, they're implementing 1970s Lisp Machines again!
Would be a godsend for GC, much better than malloc/free safety checks. There are small boards with HW assisted GC support, 2bits per ptr, but no big ones as in a lispm.
Re: Memory Tagging and how it improves C/C++ memory safety
#40A long time ago I found some memory problems in a C++ codebase we had inherited and that crashes from time. In Windows you can protect memory blocks with a function call so I overloaded new and malloc and added some protected blocks before and after the actual memory. Then we ran the code for a lot and it would fault right at the point of the memory overwrite instead of some place later. It made the code very slow bu…
We did the same thing for some device driver code and also use a tool called "Boundschecker", back in the 90s. I just checked and it still exists!
[deleted]