From nobody Sat Jun 13 16:21:59 2026 Received: from mailout1.hostsharing.net (mailout1.hostsharing.net [83.223.95.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 26A9F3F0ABE; Wed, 6 May 2026 13:27:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.223.95.204 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778074070; cv=none; b=r5/HiJut1BVVa022C0kHfu+mgOU0zQc+hDE9yLIeQ4r+AJWP5Wkev4h1TIQpI/YfkRAUyTq5L70Mob0v3aJ9zR4MWwOE36ISZ5ZMAH1Jyn0D9FBhxtO7BwAvLmvPiA7qiCCBoVt/3Fzoo3GFyiQUfZpZU3hLjTyb1tFAACap8XQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778074070; c=relaxed/simple; bh=5cF1WGzLgKm8TXk//I3thXJZYfXicmdqvKNNldydGsI=; h=Message-Id:From:Date:Subject:To:Cc; b=l5W72J+5OdcFFPWUfK9dN6OPEdUP6U6DbGhwoZknILjiKbe0HBLLfMJDZJnt29xSnB8zTTGpTtXD22s8X0FhFsiSqIzeCpX0saA9pAG2BMMMleaoonwQtJumTAO0+jhDXM+JWkHqN1V5nWiiyWIsg8MUHt2tKtTCIWbZEbB1XXc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de; spf=pass smtp.mailfrom=wunner.de; arc=none smtp.client-ip=83.223.95.204 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wunner.de Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature ECDSA (secp384r1) client-digest SHA384) (Client CN "*.hostsharing.net", Issuer "GlobalSign GCC R6 AlphaSSL CA 2025" (verified OK)) by mailout1.hostsharing.net (Postfix) with ESMTPS id 364DDF52; Wed, 06 May 2026 15:27:44 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 1F5D06001EB0; Wed, 6 May 2026 15:27:44 +0200 (CEST) Message-Id: <7e3d64a53efb28740b32d1f934e78c10086208ab.1778073318.git.lukas@wunner.de> From: Lukas Wunner Date: Wed, 6 May 2026 15:27:49 +0200 Subject: [PATCH v2] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y To: Herbert Xu , "David S. Miller" , Andrew Morton Cc: Arnd Bergmann , Andrey Ryabinin , Ignat Korchagin , Stefan Berger , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andy Shevchenko , Eric Biggers , Nathan Chancellor , David Laight , "Jason A. Donenfeld" , Ard Biesheuvel Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 1= 280 bytes [-Werror=3Dframe-larger-than=3D] 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=3Dy, 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=3Dframe-larger-than=3D1280 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=3D100 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=3D124949 Reported-by: Andrew Morton # off-list Signed-off-by: Lukas Wunner Acked-by: Andy Shevchenko Reviewed-by: Andy Shevchenko --- Changes v1 -> v2: * s/ARCH/CONFIG_ARM/, s/LLVM/CONFIG_CC_IS_GCC/ (Nathan) * Add link to gcc bugzilla entry * Rewrite commit message to include feedback provided by gcc maintainers and explain high stack usage with algorithm choice Link to v1: https://lore.kernel.org/r/abfaede9ab2e963d784fb70598ed74935f7f8d93.17756284= 69.git.lukas@wunner.de/ crypto/Makefile | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/crypto/Makefile b/crypto/Makefile index 1622425..c73f4d5 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -178,6 +178,11 @@ obj-$(CONFIG_CRYPTO_ZSTD) +=3D zstd.o obj-$(CONFIG_CRYPTO_ECC) +=3D ecc.o obj-$(CONFIG_CRYPTO_ESSIV) +=3D essiv.o =20 +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D124949 +ifeq ($(CONFIG_ARM)$(CONFIG_KASAN_STACK)$(CONFIG_CC_IS_GCC),yyy) +CFLAGS_ecc.o +=3D $(call cc-option,-Wframe-larger-than=3D1536) +endif + ecdh_generic-y +=3D ecdh.o ecdh_generic-y +=3D ecdh_helper.o obj-$(CONFIG_CRYPTO_ECDH) +=3D ecdh_generic.o --=20 2.51.0