Re: [PATCH 10/11] x86/purgatory: Compile purgatory.c with -D__NO_FORTIFY

[Thomas Huth]

On 14/08/2026 17.24, Borislav Petkov wrote:
> On Thu, Aug 13, 2026 at 03:49:48PM +0200, Thomas Huth wrote:
> > From: Thomas Huth <thuth@xxxxxxxxxx>
> >
> > purgatory.c includes both, the <crypto/sha2.h> header and the
> > arch/x86/boot/string.h header. The latter provides its own prototypes
> > for a lot of string functions which clash with the fortified macros
> > from <linux/string.h>.
> > The next patch will add #include <linux/string.h> to sha2.h to be able
>
> This is exactly the problem - people are adding main include namespace headers
> from linux/ to arch/x86/boot, or, as you do, to purgatory, which are special
> - and then they have to do all kinds of hacks so that it builds.
>
> (btw, there's no "next patch" in git history).
>
> > to use memzero_explicit() there, so we have to compile the code in
> > purgatory.c with -D__NO_FORTIFY to avoid compilation problems in this
> > file.
>
> How about you extract memzero_explicit() to a separate header in
> include/asm-generic/ or simply put it in include/asm-generic/string.h and then
> use that header instead?
>
> Then you shouldn't have prototype clashes...
>
> It does sound cleaner to me but you'd have to try it to see whether it
> actually works.
Thanks for the suggestion, I gave it a try, but I only ended up with another 
huger ugliness this way: Since memzero_explicit() needs memset(), that 
memset() has to be declared somewhere. Since I cannot include 
<linux/string.h> from the file where I put memzero_explicit(), we would need 
to make sure that all files that want to use <crypto/sha2.h> include either 
<linux/string.h> or arch/x86/boot/string.h or whatever before including 
sha2.h - i.e. this creates a likely unacceptable indirect dependency of 
sha2.h on including a string.h header first.

Adding the -D__NO_FORTIFY to the purgatory Makefile sounds like the lesser 
of the two evils to me, especially since there is already another line in 
that Makefile that adds -D__NO_FORTIFY to one of the other files there:

 CFLAGS_sha256.o := -D__DISABLE_EXPORTS -D__NO_FORTIFY

Maybe I should rather change the patch to add -D__NO_FORTIFY unconditionally 
to generic PURGATORY_CFLAGS there? Something like:

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -11,7 +11,7 @@ $(obj)/string.o: 
$(srctree)/arch/x86/boot/compressed/string.c FORCE
 $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE
        $(call if_changed_rule,cc_o_c)

-CFLAGS_sha256.o := -D__DISABLE_EXPORTS -D__NO_FORTIFY
+CFLAGS_sha256.o := -D__DISABLE_EXPORTS

 # When profile-guided optimization is enabled, llvm emits two different
 # overlapping text sections, which is not supported by kexec. Remove profile
@@ -37,6 +37,7 @@ PURGATORY_CFLAGS := -mcmodel=small -ffreestanding 
-fno-zero-initialized-in-bss -
 PURGATORY_CFLAGS += -fpic -fvisibility=hidden
 PURGATORY_CFLAGS += $(DISABLE_KSTACK_ERASE) -DDISABLE_BRANCH_PROFILING
 PURGATORY_CFLAGS += -fno-stack-protector
+PURGATORY_CFLAGS +=  -D__NO_FORTIFY

 # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
 # in turn leaves some undefined symbols like __fentry__ in purgatory and not

WDYT?

 Thomas