Re: [PATCH 2/2] meson: mitigate against use of uninitialize stack for exploits

[Thomas Huth <thuth@redhat.com>]

On 05/10/2023 19.38, Daniel P. Berrangé wrote:
> 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 2003ca1ba4..19faea8d30 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -442,6 +442,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-var-auto-init=zero',
>   ]

I was a little bit torn about using =zero when I first read your patch, but 
after looking at [1], I tend now also tend to agree that =zero is likely the 
best choice. So from my side:

Reviewed-by: Thomas Huth <thuth@redhat.com>