fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.
ChkTag: x86 Memory Safety
41–50 of 147 posts
Re: ChkTag: x86 Memory Safety
#42Earlier quoted context omitted.
Dynamic types have classically used the lower bits freed by alignment constraints. If I know a cons cell is 16 bytes then I can use the low 4 bits of an address to store enough type info to disambiguate.
Is it a guarantee that a 16 byte object would be 16 byte aligned?
In C++ you can force that with alignas(), I would imagine other low level languages offer something similar.
If you're using a custom allocator you'd have to enfore it yourself which should be fine since you have full control.
Re: ChkTag: x86 Memory Safety
#43Garbage article. Like, cool, you guys are starting to talk about a new instruction set that will make C safe somehow. Yet you failed provide an ounce of detail for how you'll accomplish that. This might as well been a "And we'll make our CPUs 10x faster and they'll use 10x less power!". Or "Future CPUs will have a 10ghz clock speed!" Again, who is this article for? The government maybe to assure them that x86 will ta…
Given that this technique is used in production for all current gen Iphones should tell you this isn't vaporware.
What technique? There's no technique described in the article. It's just a long article about why this is needed, an announcement of collaboration, and naming the set of instructions.
Re: ChkTag: x86 Memory Safety
#44Earlier quoted context omitted.
Dynamic types have classically used the lower bits freed by alignment constraints. If I know a cons cell is 16 bytes then I can use the low 4 bits of an address to store enough type info to disambiguate.
Is it a guarantee that a 16 byte object would be 16 byte aligned?
For memory allocation, POSIX (posix_memalign) has been guaranteeing alignment since 2001. C11 added equivalent functionality (aligned_alloc). C++17 incorporated it (std::aligned_alloc) as well.
Re: ChkTag: x86 Memory Safety
#45Sparse on details. Presumably will be based on the existing Linear Address Masking/Upper Address Ignore specs, which are equivalent, and will be similar to CHERI. If so it needs to be opt-in or at least opt-out per process, because many language runtimes use these pointers bits to optimize dynamic types, and would suffer a big performance hit if they were unable to use them.
Dynamic types have classically used the lower bits freed by alignment constraints. If I know a cons cell is 16 bytes then I can use the low 4 bits of an address to store enough type info to disambiguate.
There's a technique known as "NaN boxing" which exploits the fact double precision floats allow you to store almost 52 bits of extra data in what would otherwise be NaNs.
If you assume the top 16 bits of a pointer are unused[1], you can fit a pointer in there. This lets you store a pointer or a full double by-value (and still have tag bits left for other types!).
Last I checked LuaJIT and WebKit both still used this to represent their values.
[1] On amd64 they actually need to be sort of "sign extended" so require some fixup once extracted.
Re: ChkTag: x86 Memory Safety
#46Earlier quoted context omitted.
I'm happy another old hardware nerd got that dated reference :D. I was convinced back in the day that Larrabee would change the world. It seemed like such an amazing technology especially since multi-core CPUs were just starting to take off in consumer hardware.
Honestly it could have, if Intel had invested in the platform for more than a few generations and built the software ecosystem around it. It had on package HBM before it was cool with all the modern AI GPUs and APUs. Intel had the opportunity to build the CUDA ecosystem, and chose to shelve it. I'll never understand the obsession that new platforms must be profitable immediately. Seems they take ~10 years to develop,…
Well, they did half-heartedly try at it. Intel Phi was produced from 2010->2020.
I think the problem is that Intel pigeonholed the product, relegating it to just supercomputers. I also think Intel has historically done a bad job of supporting the software needed to power their hardware.
The reason CUDA was so successful (IMO) is because it was highly available and the software is a better quality to competitive software. OpenCL was supposed to be the answer to CUDA and ultimately it was just a weird, hard to work with, and minimally supported language.
I don't think that's all Intel's fault. Apple's dumb war against Khronos has really undermined a lot of progress for anyone doing GPGPU programming.
Re: ChkTag: x86 Memory Safety
#47Earlier quoted context omitted.
Honestly it could have, if Intel had invested in the platform for more than a few generations and built the software ecosystem around it. It had on package HBM before it was cool with all the modern AI GPUs and APUs. Intel had the opportunity to build the CUDA ecosystem, and chose to shelve it. I'll never understand the obsession that new platforms must be profitable immediately. Seems they take ~10 years to develop,…
Well, they did half-heartedly try at it. Intel Phi was produced from 2010->2020. I think the problem is that Intel pigeonholed the product, relegating it to just supercomputers. I also think Intel has historically done a bad job of supporting the software needed to power their hardware. The reason CUDA was so successful (IMO) is because it was highly available and the software is a better quality to competitive softw…
Agreed. They tried to approach the market top down, when they should know from institutional experience that bottom up wins.
Re: ChkTag: x86 Memory Safety
#48fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.
I wouldn't say that's fair. MPX failed because it was a very problematic solution to this problem.
MPX had a large (greater than 15-20%) overhead and was brittle. It didn't play well with other x86 instructions and the developer experience was extremely poor (common C and C++ design patterns would cause memory faults with MPX).
Apple MIE (which is essentially ARM MTE v2) and MTE on the other hand have near invisible levels of overhead (~5-10%) with the ability to alternate between synchronous and asynchronous tracing of faults where the latter has a much lower overhead than the former (allowing you to check in production for very little overhead and get better debugging in test). They also work essentially seamlessly with the rest of the ARM ecosystem and it takes very little to integrate the functionality into any language ecosystem or toolchain.
If MPX was comparable with MTE, it certainly would have gotten the adoption that MTE is getting but the "tech" just wasn't there to justify it's use.
Re: ChkTag: x86 Memory Safety
#49I hope there are OS level (ie kernel build options) to turn this kind of thing off or just ignore the 'tags'. I know it's important for corporate use cases and monetary transactions and all that, but on my personal computer I use for fun I want to be able to peek and poke.
If you're worried that this is going to prevent you from peeking and poking, I think you're mistaken. This is to protect a process against itself, not the outside. It will also likely be a single bit flip away of being unenforced at runtime, as most x86 protections already are to be to make debugging tools feasible.
By the way, there are already systems in place to prevent you from accessing certain memory zones. Yes, even on Linux, it's possible to make memory regions inaccessible even to root or the kernel itself. The time to be worried about that was 10 years ago.
Re: ChkTag: x86 Memory Safety
#50Earlier quoted context omitted.
Given that this technique is used in production for all current gen Iphones should tell you this isn't vaporware.
What technique? There's no technique described in the article. It's just a long article about why this is needed, an announcement of collaboration, and naming the set of instructions.
ARM has an extension called the "Memory Tagging Extension". It works by borrowing 4 bits per 16 byte block of memory to color the allocation. Pointers are given a color "key" inside the pointer during allocation and if that pointer's key isn't the right color as the underlying memory block's during deref, then the hardware throws an MTE segfault.
It's a neat system with pretty much no overhead and it's pretty easy to integrate into code as long as your underlying language and libraries are at least semi-intelligent about how they handle pointers and memory allocation (i.e. as long as you aren't doing any long range pointer punting then things "just work").
https://developer.arm.com/-/media/Arm%20Developer%20Communit...