That definition would make lots of real systems stop working, so that’s clearly the wrong direction for the spec. A good spec respects its customers.
Conversation
This Tweet was deleted by the Tweet author. Learn more
It does exist. Existing hardware has lots of safety features in hardware that are being actively used to catch these kinds of issues. More of those features are shipping over time. Intel CET and ARM MTE (which is like the existing SPARC ADI) are major examples of new features.
1
1
There is nothing about Intel CET that requires UB from the language; as I said, the compiler/spec don't have to reveal how function calls work. In my C spec, a load/store would be said to either load/store or trap, depending on how the runtime/CPU did things. So ARM MTE is OK.
1
So, it's okay to trap when indexing from one object to another and then dereferencing, or when constructing a non-derived pointer to an object in any other way and dereferencing it? That's what memory tagging will cause, since it aims to have the tags not match in those cases.
2
For example, the baseline for malloc is to set random tags for each allocation, along with adjusting them to avoid matching values for adjacent allocations. The compiler can do the same for stack frames (or even variables). Only properly derived pointers will actually work.
1
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
I'm not sure how memory tagging is a baroque addition, and what that has to do with the difficulty of mitigating side channels. Even an in-order CPU without branch prediction doesn't avoid the issues of having lots of side channels. It's a very hard problem to solve / mitigate.
1
And people are not willing to give up tons of performance. That's why memory tagging is useful, even though it provides far from full memory safety. Implementing an ABI with somewhat efficient memory safety for C is quite doable but the performance costs are still pretty huge.