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: Fri, 23 Jan 2026 08:28:38 -0800 [thread overview]
Message-ID: <aXOhtpyDMKwo0RLA@google.com> (raw)
In-Reply-To: <6752311d-f545-4148-a938-5c9690c31710@163.com>
On Fri, Jan 23, 2026, Zhiquan Li wrote:
>
> On 1/23/26 01:21, Sean Christopherson wrote:
> > 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...
>
> Thanks for your review, Sean.
>
> Unfortunately, disabling fortification only when building LIBKVM_STRING_OBJ is
> insufficient, because the definitions of the fortified versions are included by
> each caller during the preprocessing stage. I’ve done further investigation and
> found the off tracking since compilation stage with the GCC “-c -fdump-tree-all”
> options:
>
> I found memset() is replaced by __builtin___memset_chk in
> x86/nested_emulation_test.c.031t.einline phase by compiler and kept to the end.
> At last, __builtin___memset_chk was redirected to __memset_chk@plt at GLIBC in
> linking stage.
>
> As a perfect reference substance, guest_memfd_test, which invokes memset() in
> guest_code() as well. I replayed the same steps and found memset() is replaced
> by __builtin___memset_chk in guest_memfd_test.c.031t.einline phase, but, it was
> redirect to __builtin_memset in guest_memfd_test.c.103t.objsz1 phase after the
> compiler computing maximum dynamic object size for the destination. Eventually,
> __builtin_memset was redirected to memset at lib/string_override.o in linking stage.
>
> Whatever, the KVM selftests guest code should not reference to the fortified
> versions of string functions, let’s stop it at the beginning to avoid the
> compiler dancing :-) Indeed, disabling fortification for all code may seem
> overly aggressive.
Nah, that'll just turn into a game of whack-a-mole, and likely with extremely
random moles :-)
I verified the original patch fixes my problematic setup, I'll get it queued up.
Thanks!
next prev parent reply other threads:[~2026-01-23 16:28 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
2026-01-23 9:20 ` Zhiquan Li
2026-01-23 16:28 ` Sean Christopherson [this message]
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=aXOhtpyDMKwo0RLA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox