From: David Laight <David.Laight@ACULAB.COM>
To: 'Herbert Xu' <herbert@gondor.apana.org.au>,
Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Biggers <ebiggers@google.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Vitaly Chikunov <vt@altlinux.org>,
"Gilad Ben-Yossef" <gilad@benyossef.com>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] crypto: testmgr - reduce stack usage in fuzzers
Date: Mon, 17 Jun 2019 15:28:15 +0000 [thread overview]
Message-ID: <139bf69c4d35449d9b3c9265458bab42@AcuMS.aculab.com> (raw)
In-Reply-To: <20190617145624.p6alck5m6bqaswgp@gondor.apana.org.au>
From: Herbert Xu
> Sent: 17 June 2019 15:56
> On Mon, Jun 17, 2019 at 04:54:16PM +0200, Arnd Bergmann wrote:
> >
> > Just converting the three testvec_config variables is what I originally
> > had in my patch. It got some configurations below the warning level,
> > but some others still had the problem. I considered sending two
> > separate patches, but as the symptom was the same, I just folded
> > it all into one patch that does the same thing in four functions.
>
> Just curious, how bad is it with only moving testvec_config off
> the stack?
This all reminds me of some code I wrote a long time ago (1984?)
that worked out the maximum stack use for a system by processing
all the .o files to find out which functions called which at what
stack depth and adding everything up.
That system had no indirect calls and no recursion, but the worst
stack use was always in diagnostic prints in obscure error paths.
My guess is that the same is true for the Linux kernel.
While getting rid of large on-stack buffers fixes the obvious cases
full analysis is needed to guarantee the stack won't overflow.
Doing that requires some method for determining the stack use
of indirect calls - which really requires knowing which type of
function is actually being called from each place.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2019-06-17 15:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 13:23 Arnd Bergmann
2019-06-17 14:04 ` Herbert Xu
2019-06-17 14:10 ` Arnd Bergmann
2019-06-17 14:24 ` Herbert Xu
2019-06-17 14:54 ` Arnd Bergmann
2019-06-17 14:56 ` Herbert Xu
2019-06-17 15:22 ` Arnd Bergmann
2019-06-17 15:28 ` David Laight [this message]
2019-06-17 17:20 ` Eric Biggers
2019-06-17 20:05 ` Arnd Bergmann
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=139bf69c4d35449d9b3c9265458bab42@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=ebiggers@google.com \
--cc=gilad@benyossef.com \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vt@altlinux.org \
/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
Powered by JetHome