]> git.ipfire.org Git - thirdparty/qemu.git/commit
meson: mitigate against use of uninitialize stack for exploits
authorDaniel P. Berrangé <berrange@redhat.com>
Wed, 3 Jan 2024 12:34:14 +0000 (12:34 +0000)
committerThomas Huth <thuth@redhat.com>
Tue, 16 Jan 2024 06:25:27 +0000 (07:25 +0100)
commit7ff9ff039380008952c6fd32011dd2a4d5666906
treee85d24950cb4e495c0578e8ef6cfc548345337ce
parent043eaa0f0c8618382b2dba2f2e4fe762215b2e29
meson: mitigate against use of uninitialize stack for exploits

When variables are used without being initialized, there is potential
to take advantage of data that was pre-existing on the stack from an
earlier call, to drive an exploit.

It is good practice to always initialize variables, and the compiler
can warn about flaws when -Wuninitialized is present. This warning,
however, is by no means foolproof with its output varying depending
on compiler version and which optimizations are enabled.

The -ftrivial-auto-var-init option can be used to tell the compiler
to always initialize all variables. This increases the security and
predictability of the program, closing off certain attack vectors,
reducing the risk of unsafe memory disclosure.

While the option takes several possible values, using 'zero' is
considered to be the  option that is likely to lead to semantically
correct or safe behaviour[1]. eg sizes/indexes are not likely to
lead to out-of-bounds accesses when initialized to zero. Pointers
are less likely to point something useful if initialized to zero.

Even with -ftrivial-auto-var-init=zero set, GCC will still issue
warnings with -Wuninitialized if it discovers a problem, so we are
not loosing diagnostics for developers, just hardening runtime
behaviour and making QEMU behave more predictably in case of hitting
bad codepaths.

[1] https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html

Signed-off-by: "Daniel P. Berrangé" <berrange@redhat.com>
Message-ID: <20240103123414.2401208-3-berrange@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
meson.build