> -----Original Message----- > From: Arnd Bergmann <arnd@xxxxxxxx> > Sent: Monday, September 30, 2019 10:12 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: Antoine Tenart <antoine.tenart@xxxxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; > David S. Miller <davem@xxxxxxxxxxxxx>; Pascal van Leeuwen <pascalvanl@xxxxxxxxx>; Ard > Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; linux- > crypto@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 2/3] crypto: inside-secure - Reduce stack usage > > On Mon, Sep 30, 2019 at 9:04 PM Pascal Van Leeuwen > <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > > > > Alternatively, it should be possible to shrink these allocations > > > as the extra buffers appear to be largely unnecessary, but doing > > > this would be a much more invasive change. > > > > > Actually, for HMAC-SHA512 you DO need all that buffer space. > > You could shrink it to 2 * ctx->state_sz but then your simple indexing > > is no longer going to fly. Not sure if that would be worth the effort. > > Stack allocations can no longer be dynamically sized in the kernel, > so that would not work. > I was actually referring to your kzalloc, not to the original stack based implementation ... > What I noticed though is that the largest part of safexcel_ahash_export_state > is used in the 'cache' member, and this is apparently only referenced inside of > safexcel_hmac_init_iv, which you call twice. If that cache can be allocated > only once, you save SHA512_BLOCK_SIZE bytes in one of the two paths. > Well ... hmmm ... "my"... This is not originally "my" code. And until you brought this up, I did not fully realise it was using this export_state struct to store those digests. Seems to have something to do with directly taking the crypto_ahash_export state output, which is much more than that, in case you need to continue the hash (which you don't here). I guess you need to "catch" that output somewhere, so probably you could save a bit of memory but I doubt it would be a significant improvement. > > I don't like the part where you dynamically allocate the cryto_aes_ctx > > though, I think that was not necessary considering its a lot smaller. > > I count 484 bytes for it, which is really large. > Maybe I should've counted myself ... totally unexpectedly huge. Why?? Anyway, glad I got rid of it already then. > > And it conflicts with another change I have waiting that gets rid of > > aes_expandkey and that struct alltogether (since it was really just > > abused to do a key size check, which was very wasteful since the > > function actually generates all roundkeys we don't need at all ...) > > Right, this is what I noticed there. With 480 of the 484 bytes gone, > you are well below the warning limit even without the other change. > And by "other change" you mean the safexcel_ahash_export_state? Ok, good to known, although I do like to improve that one as well, but preferably by not exporting the cache so I don't need the full struct. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
