lkml.org 
[lkml]   [2019]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] crypto: testmgr - reduce stack usage in fuzzers
    On Mon, Jun 17, 2019 at 7:20 PM Eric Biggers <ebiggers@kernel.org> wrote:
    > On Mon, Jun 17, 2019 at 03:23:02PM +0200, Arnd Bergmann wrote:
    > > On arm32, we get warnings about high stack usage in some of the functions:
    > >

    > > @@ -1541,6 +1543,10 @@ static void generate_random_hash_testvec(struct crypto_shash *tfm,
    > > done:
    > > snprintf(name, max_namelen, "\"random: psize=%u ksize=%u\"",
    > > vec->psize, vec->ksize);
    > > +
    > > + kfree(desc);
    > > +
    > > + return 0;
    > > }
    >
    > Instead of allocating the here, can you allocate it in
    > test_hash_vs_generic_impl() and call it 'generic_desc'? Then it would match
    > test_skcipher_vs_generic_impl() and test_aead_vs_generic_impl() which already
    > dynamically allocate their skcipher_request and aead_request, respectively.

    Ok, good idea. I could not find an equivalent of skcipher_request_alloc()
    and skcipher_request_free(), so I ended up open-coding those.

    > > @@ -1565,7 +1571,7 @@ static int test_hash_vs_generic_impl(const char *driver,
    > > unsigned int i;
    > > struct hash_testvec vec = { 0 };
    > > char vec_name[64];
    > > - struct testvec_config cfg;
    > > + struct testvec_config *cfg;
    > > char cfgname[TESTVEC_CONFIG_NAMELEN];
    > > int err;
    > >
    >
    > Otherwise I guess this patch is fine for now, though there's still a lot of
    > stuff with nontrivial size on the stack (cfgname, vec_name, _generic_driver,
    > hash_testvec, plus the stuff in test_hash_vec_cfg). There's also still a
    > testvec_config on the stack in test_{hash,skcipher,aead}_vec(); I assume you
    > didn't see a warning there only because it wasn't in combination with as much
    > other stuff on the stack.

    Right, the stack usage for the other function is still several the hundreds of
    bytes, but it falls under the radar of the 1024 byte warning limit.

    > I should probably have a go at refactoring this code to pack up most of this
    > stuff in *_params structures, which would then be dynamically allocated much
    > more easily.

    Makes sense. I'll leave that up to you, and will repost a set of two patches
    based on your suggestion for testvec_config (unchanged) and
    test_hash_vs_generic_impl, after build testing my current patches over night.

    Arnd

    \
     
     \ /
      Last update: 2019-06-17 22:06    [W:3.055 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site