lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aXJcpzcoHIRi3ojE@google.com>
Date: Thu, 22 Jan 2026 09:21:43 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Zhiquan Li <zhiquan_li@....com>
Cc: pbonzini@...hat.com, shuah@...nel.org, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some
 unpredictable test failures

On Thu, Jan 22, 2026, Zhiquan Li wrote:
> Some distributions (such as Ubuntu) configure GCC so that
> _FORTIFY_SOURCE is automatically enabled at -O1 or above.  This results
> in some fortified version of definitions of standard library functions
> are included.  While linker resolves the symbols, the fortified versions
> might override the definitions in lib/string_override.c and reference to
> those PLT entries in GLIBC.  This is not a problem for the code in host,
> but it is a disaster for the guest code.  E.g., if build and run
> x86/nested_emulation_test on Ubuntu 24.04 will encounter a L1 #PF due to
> memset() reference to __memset_chk@....

Ugh.  I'm pretty sure I saw this recently as well (I forget what OS), and I was
completely clueless as to why it was failing.  Thanks a ton for tracking this
down!

> The option -fno-builtin-memset is not helpful here, because those
> fortified versions are not built-in but some definitions which are
> included by header, they are for different intentions.
> 
> In order to eliminate the unpredictable behaviors may vary depending on
> the linker and platform, add the "-U_FORTIFY_SOURCE" into CFLAGS to
> prevent from introducing the fortified definitions.
> 
> Signed-off-by: Zhiquan Li <zhiquan_li@....com>
> ---
>  tools/testing/selftests/kvm/Makefile.kvm | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> index ba5c2b643efa..d45bf4ccb3bf 100644
> --- a/tools/testing/selftests/kvm/Makefile.kvm
> +++ b/tools/testing/selftests/kvm/Makefile.kvm
> @@ -251,6 +251,7 @@ LINUX_TOOL_INCLUDE = $(top_srcdir)/tools/include
>  LINUX_TOOL_ARCH_INCLUDE = $(top_srcdir)/tools/arch/$(ARCH)/include
>  CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \
>  	-Wno-gnu-variable-sized-type-not-at-end -MD -MP -DCONFIG_64BIT \
> +	-U_FORTIFY_SOURCE \

Is this needed for _all_ code, or would it suffice to only disable fortification
when building LIBKVM_STRING_OBJ?  From the changelog description, it sounds like
we need to disable fortification in the callers to prevent a redirect, but just
in case I'm reading that wrong...

>  	-fno-builtin-memcmp -fno-builtin-memcpy \
>  	-fno-builtin-memset -fno-builtin-strnlen \
>  	-fno-stack-protector -fno-PIE -fno-strict-aliasing \
> -- 
> 2.43.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ