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.
Conversation
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
But making it traps breaks real C code, so it can't be what the spec says.
Good specs respect their existing clients!
1
Forbidding trapping also breaks widely deployed existing implementations, so you can't do that either per your own rules, sorry.
1
1
This Tweet was deleted by the Tweet author. Learn more
It's always implemented in software via hardware features. The features vary in performance. Jump-on-overflow is a lot worse than architectures with support for enabling a trapping mode, whether it's strict or propagates a poison value that can never be accessed (since it traps).
1
1
Hardware doesn't implement C, so there isn't a standard behavior defined by hardware. It's up to the compiler to map C onto the hardware or the virtual machine. They get to choose how to handle each kind of undefined or implementation defined behavior, and everything else.
2
1
Clang could decide they want to implement a fully portable, well-defined behavior for overly long shifts. That could mean trapping, or it could mean choosing a common hardware behavior and matching it everywhere. They do a lot of this. They aren't just exposing hardware features.
Yeah, and I'm arguing for masking the shift amount.
1
That's fine, as long as trapping implementations are still considered fully compliant as they are today. Otherwise, I prefer the current approach. I'm not sure what the point is of going over the same things again and again.