Consider `-fzero-init-padding-bits=all` for C and C++ Compiler Hardening Guide

[thomasnyman]

GCC 15 is expected to alter its behavior with respect to initializing padding
bits in unions and structures where the standard doesn't require it, e.g.,

void foo (void)
{
	union U { int a; long b[64]; };
        /* C23 requires padding bits to be cleared here.  */
	union U u = {};
	
        /* In GCC 14 an earlier, this clear everything, but only clears v.a in GCC 15 by default.  */
	union U v = {0};
}

void bar (void)
{
	struct S { char a; int b; };
	/* C23 requires padding bits to be cleared here.  */
	struct S s = {};
	/* n GCC 14 an earlier this would also clear padding bits, but in GCC 15 this is not longer the case. */
	struct S t = { 1, 2 };
}

Developers might want to retain the behavior in GCC 14 and earlier to avoid uninitialized padding bits from leaking information in cases where structures are passed across security boundaries, e.g., userspace / kernelspace boundary, to sandboxed code etc. In the case of unions the -fzero-init-padding-bits=unions can be used to restore previous behavior and -fzero-init-padding-bits=all restores the GCC 14 behavior in both of the above cases.

Another alternative is the use of the __builtin_clear_padding though it doesn't clear bits in unions unless they are padding bits for all possible members.

Thanks to @fuhsnn for pointing this out (I was taking notes)

Resources:

• https://news.ycombinator.com/item?id=43535105
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403
• https://lore.kernel.org/linux-toolchains/Z0hRrrNU3Q+ro2T7@tucnak/
• https://patchwork.kernel.org/project/linux-kbuild/patch/20250127191031.245214-3-kees@kernel.org/

[thomasnyman]

GCC 15.1 was released on April 25th and the the Changes file covers this news behavior as follows:

{0} initializer in C or C++ for unions no longer guarantees clearing of the whole union (except for static storage duration initialization), it just initializes the first union member to zero. If initialization of the whole union including padding bits is desirable, use {} (valid in C23 or C++) or use -fzero-init-padding-bits=unions option to restore old GCC behavior.

[david-a-wheeler]

I support adding -fzero-init-padding-bits=all to the list of options; it's a quiet change that might unexpectedly disclose data that previously was zerod. While C23 added {}, older compilers still in use might not support the official alternative. Even worse, some developers won't hear about this and will use the old way that worked - not realizing this no longer works.

I think this is GCC-specific, yes? It'd be good if clang could add the same, but we can mark it as GCC specific for now if we must.

I recommend adding something like this to the section "How should this guide be applied?" as I think this provides a useful broader context:

We encourage developers to always use the approach guaranteed by standards to do something, as long as it's supported by their build processes. For example, in C23 or C++, assigning {} to a union guarantees the clearing of a whole union including padding bits (except for static storage duration initialization). Assigning {0} to a union does not guarantee clearing the whole union (e.g., in GCC 14 and below, this cleared a union, but in GCC 15 it does not). Using the standards' approach greatly reduces the risk that using a different compiler or a different compiler version will cause problems. That said, there may be no mechanism in the standards to do something, sometimes compilers don't implement the standard way, and developers sometimes make mistakes. Thus, using option flags in addition to working within the standards where practical can be a powerful combination.

Then in the discussion recommending -fzero-init-padding-bits=all, note something like:

This flag reduces the risk that an incomplete initialization reveals sensitive information.

We recommend that unions be assigned {} to clear them, as this is supported by the C23 and C++ standards. However, older code may use a different approach, some compilers may not support it, and developers sometimes make mistakes, so this option reduces the risk of such problems.