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] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r077j1fa.fsf@gentoo.org>
Date: Tue, 19 Nov 2024 04:24:41 +0000
From: Sam James <sam@...too.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Kostadin Shishmanov <kostadinshishmanov@...tonmail.com>,
  "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
  arnd@...db.de,  linux-kbuild@...r.kernel.org
Subject: Re: Build failure with GCC 15 (-std=gnu23)

Nathan Chancellor <nathan@...nel.org> writes:

> On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote:
>> Nathan Chancellor <nathan@...nel.org> writes:
>> 
>> > Hi Kostadin,
>> >
>> > Just a quick FYI off the bat, you only directed this to LKML, which is
>> > basically like sending it into the void because very few people actually
>> > read every message on LKML. I only caught it because I have a filter set
>> > up for mentions of Clang and LLVM. I'd suggest adding at least the
>> > Kbuild mailing list, which I have done now. I have also added Arnd
>> > because I seem to recall him looking into how hard it would be to build
>> > the kernel with C23.
>> 
>> FWIW, scripts/get_maintainers.pl for stddef.h and types.h doesn't
>> include kbuild -- maybe we should add that in.
>
> Yeah, it would be good to have someone own these files. Not sure it
> makes sense for Kbuild to be it though, I merely suggested that since
> the actual root cause of the error is more in Kbuild's realm.

Yeah, I couldn't figure out who a better person would be either :|

>
>> I can reproduce it with `make defconfig` at
>> 158f238aa69d91ad74e535c73f552bd4b025109c in Linus' tree with just `make
>> V=1 -j$(nproc) -l$(nproc)` (i.e. no CFLAGS manipulation at all).
>> 
>> ```
>> # CC      drivers/firmware/efi/libstub/x86-5lvl.o
>>   gcc -Wp,-MMD,drivers/firmware/efi/libstub/.x86-5lvl.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/genera
>> ted/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__
>>  -fmacro-prefix-map=./= -mcmodel=small -m64 -D__KERNEL__ -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -Wno-pointer-sign -Wno-address-of-packed-member -fno-asy
>> nchronous-unwind-tables -Os -DDISABLE_BRANCH_PROFILING -include ./include/linux/hidden.h -D__NO_FORTIFY -ffreestanding -fno-stack-protector -D__DISABLE_EXPORTS    -DKBUILD_MODFILE='"driv
>> ers/firmware/efi/libstub/x86-5lvl"' -DKBUILD_BASENAME='"x86_5lvl"' -DKBUILD_MODNAME='"x86_5lvl"' -D__KBUILD_MODNAME=kmod_x86_5lvl -c -o drivers/firmware/efi/libstub/x86-5lvl.o drivers/fi
>> rmware/efi/libstub/x86-5lvl.c
>> In file included from ./include/uapi/linux/posix_types.h:5,
>>                  from ./include/uapi/linux/types.h:14,
>>                  from ./include/linux/types.h:6,
>>                  from ./include/linux/kasan-checks.h:5,
>>                  from ./include/asm-generic/rwonce.h:26,
>>                  from ./arch/x86/include/generated/asm/rwonce.h:1,
>>                  from ./include/linux/compiler.h:317,
>>                  from ./include/linux/build_bug.h:5,
>>                  from ./include/linux/init.h:5,
>>                  from ./include/linux/efi.h:15,
>>                  from drivers/firmware/efi/libstub/file.c:10:
>> ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
>>    11 |         false   = 0,
>>       |         ^~~~~
>> ```
>> 
>> -std=gnu11 certainly isn't there.
>
> Ugh, this is because drivers/firmware/efi/libstub does not use
> KBUILD_CFLAGS from the rest of the kernel when targeting x86:
>
> $ sed -n '9,21p' drivers/firmware/efi/libstub/Makefile
> # non-x86 reuses KBUILD_CFLAGS, x86 does not
> cflags-y                        := $(KBUILD_CFLAGS)
>
> cflags-$(CONFIG_X86_32)         := -march=i386
> cflags-$(CONFIG_X86_64)         := -mcmodel=small
> cflags-$(CONFIG_X86)            += -m$(BITS) -D__KERNEL__ \
>                                    -fPIC -fno-strict-aliasing -mno-red-zone \
>                                    -mno-mmx -mno-sse -fshort-wchar \
>                                    -Wno-pointer-sign \
>                                    $(call cc-disable-warning, address-of-packed-member) \
>                                    $(call cc-disable-warning, gnu) \
>                                    -fno-asynchronous-unwind-tables \
>                                    $(CLANG_FLAGS)
>
> This isn't the first time this peculiarity has bitten us :/ sticking
> '-std=gnu11' in there should resolve that issue.
>
> arch/x86/boot/compressed/Makefile might need the same treatment. It
> might make sense to introduce something like 'CSTD_FLAG := -std=gnu11'
> then use that in the various places within the kernel that need it so it
> can be consistently updated in the future whenever needed. I see that
> flag in Makefile, arch/arm64/kernel/vdso32/Makefile, and
> arch/x86/Makefile.

This is the conclusion I just reached, although I'm struggling to figure
out a nice place to put it without sprinkling it all over the place. I'm
inclined to wait until kbuild folks weigh in so I don't do a lot of
(trivial, but tedious) work that needs changing.

As a hack, I've injected it into CLANG_FLAGS locally for now as it
happens to appear in all the right places ;)

>
> Cheers,
> Nathan

thanks,
sam

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ