mbox series

[0/2] topic: meson: add more compiler hardening flags

Message ID 20231005173812.966264-1-berrange@redhat.com
Headers show
Series topic: meson: add more compiler hardening flags | expand

Message

Daniel P. Berrangé Oct. 5, 2023, 5:38 p.m. UTC 
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(+)

Comments

Thomas Huth Oct. 9, 2023, 7:21 a.m. UTC | #1 
On 05/10/2023 19.38, Daniel P. Berrangé wrote:
...
> 
> 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 ?
I'm not an expert when it comes to this question, but as far as I 
understood, we are using -fwrapv (with "w", not "t") on purpose, see 
meson.build:

# We use -fwrapv to tell the compiler that we require a C dialect where
# left shift of signed integers is well defined and has the expected
# 2s-complement style results. (Both clang and gcc agree that it
# provides these semantics.)

And according to the man-page of gcc:

  The options -ftrapv and -fwrapv override each other,
  so using -ftrapv -fwrapv on the command-line results
  in -fwrapv being effective.

If I got that right, this means you cannot use -ftrapv with QEMU.

  Thomas
Daniel P. Berrangé Oct. 9, 2023, 8:32 a.m. UTC | #2 
On Mon, Oct 09, 2023 at 09:21:01AM +0200, Thomas Huth wrote:
> On 05/10/2023 19.38, Daniel P. Berrangé wrote:
> ...
> > 
> > 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 ?
> I'm not an expert when it comes to this question, but as far as I
> understood, we are using -fwrapv (with "w", not "t") on purpose, see
> meson.build:
> 
> # We use -fwrapv to tell the compiler that we require a C dialect where
> # left shift of signed integers is well defined and has the expected
> # 2s-complement style results. (Both clang and gcc agree that it
> # provides these semantics.)
> 
> And according to the man-page of gcc:
> 
>  The options -ftrapv and -fwrapv override each other,
>  so using -ftrapv -fwrapv on the command-line results
>  in -fwrapv being effective.
> 
> If I got that right, this means you cannot use -ftrapv with QEMU.

Opps, I didn't notice we had -fwrapv in our flags, that is clearly
mutually exclusive with -ftrapv, so nothing further to do here.

With regards,
Daniel