From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: [PATCH 0/2] topic: meson: add more compiler hardening flags
Date: Thu, 5 Oct 2023 18:38:10 +0100 [thread overview]
Message-ID: <20231005173812.966264-1-berrange@redhat.com> (raw)
This brings more compiler hardening flags to the default QEMU
build process. The proposed flags have already been adopted by
default in the kernel build process. At some point it is hoped
that distros might enable them globally, as they've done in
the past with things like _FORTIFY_SOURCE. Meanwhile they are
easy things to enable in QEMU which have negligible cost and
clear benefits to hardening. Considering QEMU shows no signs
of stoppping the flow of guest triggerable CVEs, investing in
hardening is worthwhile. See the respective commit messages
for details
I also tested enabling -ftrapv, to change signed integer
overflow from wrapping, to trapping instead. This exposed a
bug in the string-input-visitor which overflows when parsing
ranges, and exposed the test-int128 code as (harmlessly)
overflowing during its testing. Both can be fixed, but I'm
not entirely sure whether -ftrapv is viable or not. I was
wondering about TCG and whether it has a need to intentionally
allow integer overflow for any of its instruction emulation
requirements ? "make check" passes qtest but that's not
sufficiently broad to make me comfortable. Thus I've not
included an -ftrapv patch here.
Daniel P. Berrangé (2):
meson: mitigate against ROP exploits with -fzero-call-used-regs
meson: mitigate against use of uninitialize stack for exploits
meson.build | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--
2.41.0
next reply other threads:[~2023-10-05 17:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 17:38 Daniel P. Berrangé [this message]
2023-10-05 17:38 ` [PATCH 1/2] meson: mitigate against ROP exploits with -fzero-call-used-regs Daniel P. Berrangé
2023-10-09 7:35 ` Thomas Huth
2023-10-05 17:38 ` [PATCH 2/2] meson: mitigate against use of uninitialize stack for exploits Daniel P. Berrangé
2023-10-09 7:44 ` Thomas Huth
2023-10-09 10:15 ` Thomas Huth
2023-10-09 11:05 ` Daniel P. Berrangé
2023-10-09 7:21 ` [PATCH 0/2] topic: meson: add more compiler hardening flags Thomas Huth
2023-10-09 8:32 ` 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=20231005173812.966264-1-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).