Re: Setting a default value for OPT_INIT_ALL (stable=zero, current=pattern)

On Sat, Jan 11, 2025 at 08:44:47PM +0000, Shawn Webb wrote:
> On Sat, Jan 11, 2025 at 08:18:27PM +0000, Shawn Webb wrote:
> > On Sat, Jan 11, 2025 at 08:43:13PM +0100, Alexander Leidinger wrote:
> > > Hi,
> > > 
> > > we have support to set a default initialization value for uninitialized
> > > variables (OPT_INIT_ALL in src.conf). Possible values are (copy&paste from
> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565514.html):
> > > '-ftrivial-auto-var-init=CHOICE'
> > >      Initialize automatic variables with either a pattern or with zeroes
> > >      to increase program security by preventing uninitialized memory
> > >      disclosure and use.
> > > 
> > >      The three values of CHOICE are:
> > > 
> > >         * 'uninitialized' doesn't initialize any automatic variables.
> > >           This is C and C++'s default.
> > > 
> > >         * 'pattern' Initialize automatic variables with values which
> > >           will likely transform logic bugs into crashes down the line,
> > >           are easily recognized in a crash dump and without being values
> > >           that programmers can rely on for useful program semantics.
> > >           The values used for pattern initialization might be changed in
> > >           the future.
> > > 
> > >         * 'zero' Initialize automatic variables with zeroes.
> > > 
> > >      The default is 'uninitialized'.
> > > 
> > > The main point of this option is to prevent leaking random data by accident.
> > > 
> > > What I propose is to have OPT_INIT_ALL set to "zero" in stable branches. We
> > > could maybe also set it to "pattern" in -current. In my opinion this a
> > > similar thing like the malloc production setting, or witness, and so on.
> > > 
> > > Any thoughts about this?
> > > 
> > > In case of a generic consensus of this, I would expect the release
> > > engineering team to take this into their procedure for branching a new
> > > stable branch. The locations where a OPT_INIT_ALL?=zero would need to be
> > > added are share/mk/bsd.lib.mk, share/mk/bsd.prog.mk and sys/conf/kern.mk.
> > 
> > Hey Alex,
> > 
> > To give some additional data points coming from the HardenedBSD side:
> > 
> > 1. In 2019, we added support for this feature on an opt-in basis.
> >    * Commit 6b573e328baa44bf8b47d40ff72fc1cc8a86fb00
> > 2. In 2021, we enabled -ftrivial-auto-var-init=zero by default.
> >    * Commit e4494782e5015da340106ca81445c65121c55ae3
> > 3. In 2022, we modified clang itself to enable it by default.
> >    * Commit 7557c8fd656c83a21e4d43071ea502445efb1ef3
> > 4. In 2023, we added support for kernel modules to opt-in.
> >    * Commit dd21b931eca8e5370a6d0341908316538b52de71
> > 
> > The following kernel modules have opted in:
> > 
> > 1. netlink (commit 10aa23df4d0ef6a527b1f2d2092126175f64899f)
> > 2. virtio-net (commit c9a07fd0d828e4a8d0ee32f2143cca8e3eb55e8c)
> > 3. zfs (commit fdabd703d9870b00c34837299253423ab4fa8ad6)
> > 4. iwlwifi (commit 96d935f2f7328b3e2be0ceb557f09e7d2f9a9ea9)
> > 5. linuxkpi (commit 803b838923ff76660ae9f5e25696725e77deb274)
> > 6. tmpfs (commit 2e5d303a25c030664a6cbf2efd10de29de0da600)
> > 7. tarfs (commit c08174516b33c58a771c46a17d94c2ba9ed4f1a0)
> > 8. geli (commit 94ee2b3faa4712bd57f3cd82fe442b883a79b68a)
> > 9. pf (commit bd836619adb5b502c594dfab0df98e40f8adefe2)
> > 10. pfsync (commit a69ea2297d85a9537d2a08d4e4011d3e834b2cba)
> > 11. pflog (commit 0ec32fb1fd6062ca9e185e73316ff06a26a1d7af)
> > 12. vmm (commit 50d5dbec1c82cc568e0a621e4e405de7ec73b921)
> > 13. fusefs (commit 3e58a69c9b83380d77ea432e58868a0b0f3c8374)
> 
> I forgot to mention the ports tree. We ported src commit
> 7557c8fd656c83a21e4d43071ea502445efb1ef3 to:
> 
> 1. devel/llvm17 (commit 9127ee56f7ab79886b41733673550e38ca4aa96f)
> 2. devel/llvm18 (commit 9f203a68036261ed856182d15c0998c24d866066)
> 3. devel/llvm19 (commit 491ae9b6db623db60f3a8dd2e68a9ddbca7c14d7)
> 
> So ports built either with llvm-from-base or llvm{17,18,19}-from-ports
> are automatically built with -ftrivial-var-auto-init=zero. This
> provides rather significant coverage between src and ports.

Today, a vulnerability announcement against rsync demonstrates the
effectiveness of -ftrivial-auto-var-init=zero:
https://kb.cert.org/vuls/id/952657

rsync CVE-2024-12085 is fully mitigated through the use of that
compiler flag. Really cool to see a tangible example of compiler-based
mitigations in the real world.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc