From: Lukas Wunner Date: Wed, 6 May 2026 13:27:49 +0000 (+0200) Subject: crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c64ba13e2033c3c6dc1a097bf35f9f1fe457c3f7;p=thirdparty%2Fkernel%2Flinux.git crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y Andrew reports build breakage of arm allmodconfig, reproducible with gcc 14.2.0 and 15.2.0: crypto/ecc.c: In function 'ecc_point_mult': crypto/ecc.c:1380:1: error: the frame size of 1360 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] gcc aggressively inlines functions called by ecc_point_mult() (without there being any explicit inline declarations), which pushes stack usage close to the limit imposed by CONFIG_FRAME_WARN. allmodconfig implies CONFIG_KASAN_STACK=y, which increases the stack above that limit. In the bugzilla entry linked below, gcc maintainers explain that gcc estimates extra stack usage caused by inlining, but ASAN instrumentation is added in post-IPA passes and thus the inlining heuristics cannot account for it. It could be argued that -Werror=frame-larger-than=1280 instructs the compiler to avoid inlining beyond that limit lest the build breaks, which would imply gcc behaves incorrectly. But gcc maintainers reject this notion and believe that a warning switch should never affect code generation, even if it is promoted to an error. One way to unbreak the build is to limit inlining via -finline-limit=100 or by explicitly declaring some functions noinline. However while it does keep stack usage of individual functions below the limit, *total* stack usage increases. A longterm solution is to refactor ecc.c for reduced stack usage. It currently performs ECC point multiplication with a Montgomery ladder which uses co-Z (conjugate) addition to trade off memory for speed. The algorithm is susceptible to timing attacks and needs to be replaced with a constant time Montgomery ladder, which should consume less memory and thus resolve the stack usage issue as a side effect. In the interim, raise the limit for ecc.c, as is already done for several other files in the source tree. Constrain to gcc because clang 19.1.7 does not exhibit the issue. It makes do with a 724 bytes stack frame even though it inlines almost the same functions as gcc. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124949 Reported-by: Andrew Morton # off-list Signed-off-by: Lukas Wunner Acked-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Herbert Xu --- diff --git a/crypto/Makefile b/crypto/Makefile index 162242593c7c1..c73f4d51d0368 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -178,6 +178,11 @@ obj-$(CONFIG_CRYPTO_ZSTD) += zstd.o obj-$(CONFIG_CRYPTO_ECC) += ecc.o obj-$(CONFIG_CRYPTO_ESSIV) += essiv.o +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124949 +ifeq ($(CONFIG_ARM)$(CONFIG_KASAN_STACK)$(CONFIG_CC_IS_GCC),yyy) +CFLAGS_ecc.o += $(call cc-option,-Wframe-larger-than=1536) +endif + ecdh_generic-y += ecdh.o ecdh_generic-y += ecdh_helper.o obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o