linux-kernel - Re: [PATCH] KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test failures

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] [day] [month] [year] [list]

Message-ID: <aXOhtpyDMKwo0RLA@google.com>
Date: Fri, 23 Jan 2026 08:28:38 -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 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!