All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Zhiquan Li <zhiquan_li@163.com>
Cc: pbonzini@redhat.com, shuah@kernel.org, kvm@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test failures
Date: Thu, 22 Jan 2026 09:21:43 -0800	[thread overview]
Message-ID: <aXJcpzcoHIRi3ojE@google.com> (raw)
In-Reply-To: <20260122053551.548229-1-zhiquan_li@163.com>

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@plt.

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@163.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
> 

  reply	other threads:[~2026-01-22 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22  5:35 [PATCH] KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test failures Zhiquan Li
2026-01-22 17:21 ` Sean Christopherson [this message]
2026-01-23  9:20   ` Zhiquan Li
2026-01-23 16:28     ` Sean Christopherson
2026-02-04  0:10 ` Sean Christopherson

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=aXJcpzcoHIRi3ojE@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=shuah@kernel.org \
    --cc=zhiquan_li@163.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.