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.
Conversation
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
I think you're getting hung up on this idea that if the spec doesn't leave something undefined, then implementations can't *ever* deviate from what otherwise would be defined. It just means that they can't deviate by default. You can pass flags that change behavior.
1
No, that's not what I've been saying. I think it would be a serious regression to break compatibility with safe implementations by making it correct to be incompatible with them. You want to massively roll back safety and security, especially if you want to remove it by default.
2
1
You're trying to portray these safety features as a deviation from proper C, when they are fully compliant with the standard and what you want is the actual deviation from the C standard. C is not what you want it to be. You want a different language, not C.
Because they are deviations from how C currently works. They break expectations of existing C code.
1
Features like _FORTIFY_SOURCE and CFI are how C is broadly deployed in the wild. It's not a deviation from how it works. It's fully compliant with the standard and is what operating systems actually implement and enable by default, with more safety enabled by default over time.
1
Show replies
C isn't a portable assembly language. You may want it to be that but it's not. It was already pointed out that WebAssembly is a standard for what you actually want. It's a portable / well-defined low-level language. It's being extended with threads, SIMD, etc. with that approach.
1
I'm not going to write systems code in WebAssembly bytecode. I will write it in C, as will lots of other folks. Therefore, C is a portable assembly language.
1
Show replies