Re: [PATCH] lib/crypto: blake2b: Limit frame size workaround to GCC < 12.2 on i386

[david laight <david.laight@runbox.com>]

On Sat, 22 Nov 2025 11:55:31 +0100
Thorsten Blum <thorsten.blum@linux.dev> wrote:

> The GCC bug only occurred on i386 and has been resolved since GCC 12.2.
> Limit the frame size workaround to GCC < 12.2 on i386.
> 
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  lib/crypto/Makefile | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
> index b5346cebbb55..5ee36a231484 100644
> --- a/lib/crypto/Makefile
> +++ b/lib/crypto/Makefile
> @@ -33,7 +33,11 @@ obj-$(CONFIG_CRYPTO_LIB_GF128MUL)		+= gf128mul.o
>  
>  obj-$(CONFIG_CRYPTO_LIB_BLAKE2B) += libblake2b.o
>  libblake2b-y := blake2b.o
> +ifeq ($(CONFIG_X86_32),y)
> +ifeq ($(CONFIG_CC_IS_GCC)_$(call gcc-min-version, 120200),y_)
>  CFLAGS_blake2b.o := -Wframe-larger-than=4096 #  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930
> +endif # CONFIG_CC_IS_GCC
> +endif # CONFIG_X86_32

Isn't that just going to cause a run-time stack overflow?
The compile-time check is a vague attempt to stop run-type overflow by limiting
the largest single stack frames.

I can't remember the kernel stack size for x86-32, might only be 8k.

The only real solution is to either fix the source so it doesn't blow
the stack (I suspect the code is 'unrolled' and the spills everything
to stack - making it slow), or just disable the code from the build.

	David


>  ifeq ($(CONFIG_CRYPTO_LIB_BLAKE2B_ARCH),y)
>  CFLAGS_blake2b.o += -I$(src)/$(SRCARCH)
>  libblake2b-$(CONFIG_ARM) += arm/blake2b-neon-core.o