Hi! On Fri, 2022-05-06 at 20:50:08 -0700, Kees Cook wrote: > Package: dpkg-dev > Version: 1.21.7 > Severity: normal
> Please add "-ftrivial-auto-var-init=zero" for GCC 12 (which is the first > release of GCC to provide this flag). > > It goes well with the other important security flaw mitigation flags > already enabled in Debian: > https://wiki.debian.org/Hardening#dpkg-buildflags > > While many variables are initialized (due to -Wuninitialized), there is > a blind spot for variables passed by reference, padding, and cases where > -Wuninitialized just fails to track it. Universally wiping the variables > eliminates nearly the entire class of uninitialized stack variable use > (https://cwe.mitre.org/data/definitions/457.html) with nearly no overhead > (e.g. any duplicate assignments will already be squashed during dead > store elimination, etc). Ah, this flag is great, it's a pity the C standard would not declare this the default behavior though. :/ Checking https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1972043 that covers my main concerns I think. The clang position on =zero seems concerning though. I also hope no security related project is using the uninitialized memory (UB) to seed something like an PRNG or similar. :/ (Enabling this by default means that developers might fail to notice issue shadowed by this feature, and this could then affect builds on systems where this is not the default. This is less concerning when enabling it in dpkg-dev than in gcc I guess.) The usual procedure to add new default flags (in case of hardening even adding a new flag disabled by default implies more or less being enabled by default as many packages simply do hardening=+all), would be https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F, but in this case I'm not sure how useful an archive rebuild would be given that the effect would most probably be seen at run-time, but only on unexpected conditions. Still bringing this up on debian-devel would be a first. Thanks, Guillem
