[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1nOL+BbvGAM3-aiH-mfzmFYgfFL2dWJKd8=Rw-WosP=w@mail.gmail.com>
Date: Thu, 27 Aug 2020 11:19:54 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
kernel test robot <lkp@...el.com>,
Peter Oberparleiter <oberpar@...ux.ibm.com>,
Kees Cook <keescook@...omium.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
kbuild-all@...ts.01.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes
is larger than 1024 bytes
On Thu, Aug 27, 2020 at 10:42 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> In that case, I suppose we should simply disable instrumentation for
> chacha_permute()? It is a straight-forward arithmetic transformation
> on a u32[16] array, where ubsan has limited value afaict.
I guess that always works as a last resort, but shouldn't we first try
to figure out why ubsan even makes a difference and whether the
object code without ubsan looks like a reasonable representation
of the source form?
Since it really is a fairly simple transformation, I would have
expected the compiler to not emit any ubsan checks. If gcc
only gets confused about the fixed offsets possibly overflowing
the fixed-length array, maybe it helps to give it a little extra
information like (untested):
--- a/lib/crypto/chacha.c
+++ b/lib/crypto/chacha.c
@@ -13,7 +13,7 @@
#include <asm/unaligned.h>
#include <crypto/chacha.h>
-static void chacha_permute(u32 *x, int nrounds)
+static void chacha_permute(u32 x[16], int nrounds)
{
int i;
Arnd
Powered by blists - more mailing lists