[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <202305301658.BF6ECF65C@keescook>
Date: Tue, 30 May 2023 17:18:00 -0700
From: Kees Cook <keescook@...omium.org>
To: Joan Bruguera Micó <joanbrugueram@...il.com>
Cc: Thorsten Leemhuis <linux@...mhuis.info>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: build error while building arch/x86/purgatory/sha256.o: invalid
'asm': operand is not a condition code [...]
On Sun, May 28, 2023 at 04:40:31PM +0000, Joan Bruguera Micó wrote:
> I can also reproduce the problem with Arch's linux-next-git, see config:
> https://aur.archlinux.org/cgit/aur.git/tree/config?h=linux-next-git&id=f9a384e1c582321651fb613782ebc5a581146af0
>
> I've bisected it to df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3"),
> which explains why it only happens on GCC13.
Okay, this was a wild ride. Bottom line, -fstrict-flex-arrays=3 means
that CONFIG_FORTIFY_SOURCE wrappers will be included in new places now
that trailing arrays aren't ignored any more. The trailing array in
question was for struct sha256_state:
struct sha256_state {
u32 state[SHA256_DIGEST_SIZE / 4];
u64 count;
u8 buf[SHA256_BLOCK_SIZE];
};
And this "buf" is a memcpy() destination, it was being runtime bounds
checked, which means FORTIFY might emit wrappers, which will call the
WARN wrappers, which will hit this asm, which isn't supported in
purgatory.
>
> The problematic expansion that causes the error seems to be this fragment
> from `_BUG_FLAGS` in `arch/x86/include/asm/bug.h`:
> asm(".long %c0 - .\n": : "i" (__FILE__));
>
> Along with the fact that this file is built with `-mcmodel=large`
> (see `PURGATORY_CFLAGS` in `arch/x86/purgatory/Makefile`).
So, we can either disable fortify (which seems a big hammer) or disable
the warning. Disabling the warning kind of hides the problem, though
that seems to be the intention of purgatory.c's empty warn()
implementation. :P
I think it's best to disable fortify, though, as we're in a
DISABLE_EXPORTS state, and probably others are going to need it too, as
most other have already done so:
arch/arm64/kernel/pi/Makefile: -D__DISABLE_EXPORTS -ffreestanding -D__NO_FORTIFY \
arch/riscv/kernel/pi/Makefile:CFLAGS_cmdline_early.o += -D__NO_FORTIFY
arch/riscv/kernel/pi/Makefile:CFLAGS_lib-fdt_ro.o += -D__NO_FORTIFY
drivers/firmware/efi/libstub/Makefile: -D__NO_FORTIFY \
These should probably gain -D__NO_FORTIFY:
arch/riscv/purgatory/Makefile:CFLAGS_sha256.o := -D__DISABLE_EXPORTS
arch/riscv/purgatory/Makefile:CFLAGS_string.o := -D__DISABLE_EXPORTS
arch/riscv/purgatory/Makefile:CFLAGS_ctype.o := -D__DISABLE_EXPORTS
arch/s390/purgatory/Makefile:CFLAGS_sha256.o := -D__DISABLE_EXPORTS
arch/x86/purgatory/Makefile:CFLAGS_sha256.o := -D__DISABLE_EXPORTS
I'll send patches.
-Kees
--
Kees Cook
Powered by blists - more mailing lists