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

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 <[email protected]>
>>
>> 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