linux-kernel - RE: [PATCH] crypto: testmgr - reduce stack usage in fuzzers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 17 Jun 2019 15:28:15 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Herbert Xu' <herbert@...dor.apana.org.au>,
        Arnd Bergmann <arnd@...db.de>
CC:     Kees Cook <keescook@...omium.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Biggers <ebiggers@...gle.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Vitaly Chikunov <vt@...linux.org>,
        "Gilad Ben-Yossef" <gilad@...yossef.com>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] crypto: testmgr - reduce stack usage in fuzzers

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)