Cook: Security things in Linux v5.9

A static variable is initialized even if it doesn't have a explicit initializer. A stack variable isn't. You can say "ooh, it's not orthogonal" (it's not). But it's not what milesrout was referring to.

> I can't see any good reason for the difference, in terms of helping programmers write correct code.

This was not one of the prioritized goals of the C (and/or the C++) language.

> I guess the original reason was performance (zeroing .bss is much cheaper than zeroing every stack)

The current reason is still performance. Just because you have a 1990s supercomputer-level CPU/RAM/storage with ample global connectivity in your pocket doesn't mean every C program will run in similar conditions (or C++, if you remember Ingenuity is running C++ on Mars right now)

> and a lack of interest in minimising undefined behaviour (because of a lack of understanding of the security consequences)

Now you are just being facetious. People might, even when they have ample understanding of the security consequences, opt for performance. Especially if the alternative is inviabilizing a project.

> and then C/C++ kept the same behaviour mainly because it's what C/C++ programmers were already used to, not because it's actually a good design choice.

C kept the same behaviour for the reasons I stated above.

C++ actually has the same reasons, plus "upgrade path from C" and "one should not pay for what one does not use."

Sometimes it is a bug and sometimes it is not and the language gives you no way to tell whether or not it is. I consider that a bad thing. Static variables should never have been implicitly initialised, but it's obviously far too late to change that behaviour now so it's an irrelevant consideration really.

>I guess the original reason was performance (zeroing .bss is much cheaper than zeroing every stack)

Indeed the original reason was performance.

>and a lack of interest in minimising undefined behaviour (because of a lack of understanding of the security consequences),

There were no security consequences for undefined behaviour. The concept that *all* undefined behaviour is inherently a massive security hole that lets the compiler do literally any arbitrary thing is a relatively new invention based on a peculiar interpretation of the C and C++ standards by compiler developers keen to improve their scores on microbenchmarks. The contents of uninitialised variables being undefined was never meant to mean that the compiler could simply assume that code paths that didn't initialise those variables would and could never happen before other code that used those variables. Today your compiler might see 'int x; if (condition1) { x = 1; } else if (condition2) { x = 2; } else { } printf("%d\n", x);' and feel that it has the right to assume (condition1 || condition2) andis a r never even check the second condition. The standard was written as a generalisation over what existing implementations did. What is actually intended behaviour is what if you run that code it will print 1, or it will print 2, or it will print some random garbage on the stack. That might be a security hole, of course, if the function executed immediately before this one had, say, a secret key on the stack in that position. But to use a different example, it was never intended to give compilers carte blanche to do things like eliding explicit null checks for safety in code because some other code that happened to be inlined nearby assumed incorrectly the same pointer was able to be dereferenced.

>That sounds like the existing -Wuninitialized flag, though that has the challenges mentioned in https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings . It can never be perfect, even in the simple case where a variable is initialised in an "if (function_that_always_returns_true())" block, because the compiler doesn't always have visibility into that function (it might be in a separately-compiled file/library). But it's hard to even do a decent job - if the compiler doesn't do e.g. constant propagation and dead code elimination before the warnings then the programmer might get thousands of false positives in code that's obviously never going to be executed, which will make them unhappy and they'll probably just remove the warning flag; but if the compiler does do some optimisation then it's tricky to keep track of the uninitialisedness correctly.

Yes it has challenges as does any kind of static code analysis. Nonetheless it immediately becomes completely useless when 'uninitialised' ceases to be a category of variable entirely, being replaced with 'implicitly initialised to zero'.