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.
Conversation
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
No. Language says that there is no such thing as an object - it's all integer-addressed bytes. Language further acknowledges that virtual memory and trap-on-access exists. It's simple: you just write a spec of reality instead of playing silly games.
1
Okay, so you don't want SPARC ADI and ARM MTE to be used as designed in a standards compliant C implementation which the current C standard permits. It's not playing games. Having at least a weak approximation of memory safety like tagging and various other features is important.
1
1
I just made the opposite point: that MTE works fine if the language is spec'd the way I'm proposing. It allows them to be used as designed by removing the notion of malloc from the language.
1
It doesn't only impact malloc. It's designed to be usable for stack frames instead of stack canaries too. It also impacts usage of the pointers derived from what gets returned by malloc even in an implementation only using it for malloc. It doesn't only impact the malloc memory.
2
2
None of what I said relies on this being restricted to impacting malloc. You don't need UB in the language to say that stack canaries are a thing.
2
I'm talking about memory tagging as a replacement for stack canaries, not stack canaries. I'm not sure why you're responding about stack canaries. Memory tagging the stack frame makes it so that trying to use pointers to the stack frame to access memory outside it will trap.
1
1
Memory tagging works fine with the spec I'm proposing. So do stack canaries. I'm making the point that the security technologies that you are interested in (and that I'm also interested in) work fine if the language is more strongly specified.
1
Sure, and as I've stated many times in this conversation, I would like for C to be more strongly specified. However, defining something like signed integer overflow as guaranteed to wrap would be a step backwards for implementations that want to make it safer such as trapping.
2
2
Making that a second class, less supported option would also be a step backwards in this area. It would be *perfectly fine* if the standard said that signed integer overflow must either wrap or produce a poison value that is guaranteed to trap if it would be observable.
I don't think poison values are a good way to specify things. Also, the compiler would have a hard time ensuring that it knows about all the ways that the overflow has become observable (at least not without ABI changes to make each int carry an extra overflow bit with it).
1
It's important to specify it that way to permit efficient implementations. It should be allowed to have an implementation using poison values including via hardware support. There is no need for any ABI changes. Permitting trapping later doesn't mean requiring doing it later.
1
Show replies
So for example, in `printf("%d\n", a + b + c + d)`, an overflow either wraps, or has to trap at some point, either during one of the operations or when the value is read. That would be a lot better than stating that it's undefined. Guaranteed wrap would hurt safe implementations.
1
If you're going to add a trapping mode, then you'd want to add it for both signed and unsigned (unsigned gets used for address computation more frequently), and you'd want it to always trap on overflow or never trap depending on the setting.
1
Show replies