Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Lukas Wunner <lukas@wunner.de>
Cc: "David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Ignat Korchagin <ignat@linux.win>,
	Stefan Berger <stefanb@linux.ibm.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	kasan-dev@googlegroups.com,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	David Laight <david.laight.linux@gmail.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y
Date: Fri, 15 May 2026 18:21:28 +0800	[thread overview]
Message-ID: <agbzqJUnMynmxSy3@gondor.apana.org.au> (raw)
In-Reply-To: <7e3d64a53efb28740b32d1f934e78c10086208ab.1778073318.git.lukas@wunner.de>

On Wed, May 06, 2026 at 03:27:49PM +0200, Lukas Wunner wrote:
> 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 <akpm@linux-foundation.org> # off-list
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 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.1775628469.git.lukas@wunner.de/
> 
>  crypto/Makefile | 5 +++++
>  1 file changed, 5 insertions(+)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

      parent reply	other threads:[~2026-05-15 10:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 13:27 [PATCH v2] crypto: ecc - Unbreak the build on arm with CONFIG_KASAN_STACK=y Lukas Wunner
2026-05-06 13:42 ` Andy Shevchenko
2026-05-06 13:56   ` Lukas Wunner
2026-05-06 14:03     ` Andy Shevchenko
2026-05-07  4:26 ` Herbert Xu
2026-05-07  9:26   ` Andy Shevchenko
2026-05-15 10:21 ` Herbert Xu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=agbzqJUnMynmxSy3@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=Jason@zx2c4.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=david.laight.linux@gmail.com \
    --cc=dvyukov@google.com \
    --cc=ebiggers@kernel.org \
    --cc=glider@google.com \
    --cc=ignat@linux.win \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=nathan@kernel.org \
    --cc=ryabinin.a.a@gmail.com \
    --cc=stefanb@linux.ibm.com \
    --cc=vincenzo.frascino@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox