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