On Fri, 8 May 2026 at 11:47, Peter Maydell <[email protected]> wrote: > > The C standard doesn't always guarantee that struct and union padding > bits are zero initialized, even if the code initializes a struct. > For QEMU, this is potentially problematic, because we often have > structs that match data structures in guest memory, where we > initialize them and then bulk copy them into the guest. If the > compiler didn't zero init the whole of the memory containing the > struct, we could potentially leak random data from the host into the > guest via the padding bytes. > > We already use -ftrivial-auto-var-init=zero, which will zero out > padding in many of these cases, but -fzero-init-padding-bits=all > closes some gaps, for example cases where we initialize a > variable with a struct initializer, and cases involving unions. > > Follow the Linux kernel in using both options. Compare kernel > commit dce4aab8441 ("kbuild: Use -fzero-init-padding-bits=all"). > > This option exists in gcc-15 and above; it's not supported > by clang, but clang documents that it guarantees zero init > of these cases always: > https://clang.llvm.org/docs/LanguageExtensions.html#union-and-aggregate-initialization-in-c > Older gcc which don't have the option behave as if it were set. > > (These options are passed through the cc.get_supported_arguments() > filter, so we don't need to do anything extra to avoid passing it to > a compiler that doesn't recognize it.) > > Cc: [email protected] > Signed-off-by: Peter Maydell <[email protected]>
I'll take this via target-arm.next. -- PMM
