The committee finally understands that aggressively fighting basic elements of language security is a losing proposition, and all it took was the NSA and NIST saying not to use it.
At the same time you have compiler vendors (clang) and users that are already zero initializing everything anyway, and all that failing to specify this does is mean that developers can’t rely on it.
HardenedBSD recently switched to auto init to zero by default for the entire userland OS/ecosystem, including 33,000+ packages. Very quite literally zero noticeable performance hit. I would like to see a performance engineer test the before and after of our change, though.
Fixing incorrect code by making things slower for correct code. Not gonna happen.
Except auto initializing everything by default isn’t a performance hit, and pretty much every language other than C and C++ some how manages it.
Also while it took the NSA and NIST saying not use C or C++ to get WG21 to get off it’s delusional horse, the committee finally seems to have started to grasp that continuing to aggressively avoid fixing known safety problems with the language means that it will die.
I can see this as opt-in, but we already have more than a handful of ways to initialize automatic variables.
And yet 10% of CVEs are the result of uninitialized locals.
Zeroing of entire cache entries is magical, though for the stack this is rarely the case. There’s questions of temporality, special instructions, and special logic to support zeroed cachelines.
JF is the chair of the C++ standards committee language evolution group, and did much of the work making auto init viable as the default in clang. He’s still on twitter at https://twitter.com/jfbastien, but you’ll likely want to be sure you can handle many many many … many many “dad” jokes.
Not gonna actually make it through the committee. I’d bet a meal on it ($~20 pp usd).
The committee finally understands that aggressively fighting basic elements of language security is a losing proposition, and all it took was the NSA and NIST saying not to use it.
At the same time you have compiler vendors (clang) and users that are already zero initializing everything anyway, and all that failing to specify this does is mean that developers can’t rely on it.
Fixing incorrect code by making things slower for correct code. Not gonna happen.
I can see this as opt-in, but we already have more than a handful of ways to initialize automatic variables.
HardenedBSD recently switched to auto init to zero by default for the entire userland OS/ecosystem, including 33,000+ packages. Very quite literally zero noticeable performance hit. I would like to see a performance engineer test the before and after of our change, though.
Except auto initializing everything by default isn’t a performance hit, and pretty much every language other than C and C++ some how manages it.
Also while it took the NSA and NIST saying not use C or C++ to get WG21 to get off it’s delusional horse, the committee finally seems to have started to grasp that continuing to aggressively avoid fixing known safety problems with the language means that it will die.
And yet 10% of CVEs are the result of uninitialized locals.
The entire point of the proposal is that it does not slow down correct code. That’s also where most of effort was spent.
Can someone explain this a bit?
Zeroing memory is sufficiently common that processors can (and do) optimize far beyond what you’d get even just through standard write caching.
JF is the chair of the C++ standards committee language evolution group, and did much of the work making auto init viable as the default in clang. He’s still on twitter at https://twitter.com/jfbastien, but you’ll likely want to be sure you can handle many many many … many many “dad” jokes.