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.
Conversation
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.
2
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
OK, I misunderstood you to mean that you wanted to mandate trapping later. Still, you're proposing a lot of spec baggage for a questionable amount of perf. Adding baggage like this for perf ought to require a strong scientific result indicating it improves perf a lot.
1
I don't think that's a lot of spec baggage and it's required to support real implementations and software / hardware designs which you say is something that must be done by the specification. You say you want that, but then you don't when it doesn't fit making it more permissive.
1
I don't think that hardware support for poisoning is prominent enough to deserve the good kind of treatment in any language spec.
1
It's not just hardware support. It's done in software too. Implementations like UBSan aren't designed for efficiently so they just do strict checks. Efficient implementations can propagate overflow bits in software in places like loops.