[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHJrLtnJWYBKBYRtNHVS6rv51+crMsjLEnSqkud0BBaWw@mail.gmail.com>
Date: Thu, 27 Aug 2020 10:10:19 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>,
Arnd Bergmann <arnd@...db.de>
Cc: 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
(+ Arnd)
On Thu, 27 Aug 2020 at 10:06, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Thu, Aug 27, 2020 at 11:52:50AM +0800, kernel test robot wrote:
> >
> > First bad commit (maybe != root cause):
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: 15bc20c6af4ceee97a1f90b43c0e386643c071b4
> > commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move existing library code into lib/crypto
> > date: 9 months ago
> > config: i386-randconfig-r015-20200827 (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> > reproduce (this is a W=1 build):
> > git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
> > # save the attached .config to linux build tree
> > make W=1 ARCH=i386
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@...el.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> > lib/crypto/chacha.c: In function 'chacha_permute':
> > >> lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> > 65 | }
> > | ^
>
> This doesn't happen with a normal configuration. To recreate
> this warning, you need to enable both GCOV_KERNEL and UBSAN.
>
> This is the minimal gcc command-line to recreate it:
>
> gcc -Wframe-larger-than=1024 -fprofile-arcs -fsanitize=object-size -c -O2 chacha.c
>
> If you take away either profile-arcs or sanitize=object-size then
> the problem goes away.
>
> Any suggestions?
>
Is it really worth it to obsess about this? Special compiler
instrumentation simply leads to a larger stack footprint in many
cases, which is why we use a larger stack to begin with (at least we
do so for Kasan, so if we don't for Ubsan, we should consider it)
Past experience also shows that this is highly dependent on the exact
compiler version, so issues like these are often moving targets.
Powered by blists - more mailing lists