From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Thomas Huth" <thuth@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: [PATCH v2 2/2] meson: mitigate against use of uninitialize stack for exploits
Date: Wed, 3 Jan 2024 12:34:14 +0000 [thread overview]
Message-ID: <20240103123414.2401208-3-berrange@redhat.com> (raw)
In-Reply-To: <20240103123414.2401208-1-berrange@redhat.com>
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>
---
meson.build | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/meson.build b/meson.build
index eaa20d241d..efc1b4dd14 100644
--- a/meson.build
+++ b/meson.build
@@ -440,6 +440,11 @@ hardening_flags = [
# upon its return. This makes it harder to assemble
# ROP gadgets into something usable
'-fzero-call-used-regs=used-gpr',
+
+ # Initialize all stack variables to zero. This makes
+ # it harder to take advantage of uninitialized stack
+ # data to drive exploits
+ '-ftrivial-auto-var-init=zero',
]
qemu_common_flags += cc.get_supported_arguments(hardening_flags)
--
2.43.0
next prev parent reply other threads:[~2024-01-03 12:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 12:34 [PATCH v2 0/2] topic: meson: add more compiler hardening flags Daniel P. Berrangé
2024-01-03 12:34 ` [PATCH v2 1/2] meson: mitigate against ROP exploits with -fzero-call-used-regs Daniel P. Berrangé
2024-01-09 14:54 ` Markus Armbruster
2024-01-09 15:12 ` Daniel P. Berrangé
2024-01-11 12:03 ` Markus Armbruster
2024-01-03 12:34 ` Daniel P. Berrangé [this message]
2024-01-09 14:48 ` [PATCH v2 2/2] meson: mitigate against use of uninitialize stack for exploits Markus Armbruster
2024-01-09 14:53 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240103123414.2401208-3-berrange@redhat.com \
--to=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).