On Fri, Jul 13, 2018 at 3:14 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Fri, Jul 13, 2018 at 8:00 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Thu, Jul 12, 2018 at 10:20 PM, Herbert Xu >> <herbert@xxxxxxxxxxxxxxxxxxx> wrote: >>> On Thu, Jul 12, 2018 at 10:17:29PM -0700, Kees Cook wrote: >>>> What is the correct value to use for AHASH_REQUEST_ON_STACK? >>> >>> As I said to arrive at a fixed value you should examine all sync >>> ahash algorithms (e.g., all shash ones plus ahash ones marked as >>> sync if there are any). >> >> The "value" for the ahash I understand: it has a request size >> (tfm->reqsize, as set by crypto_ahash_set_reqsize()) what should be >> used to measure the shash value? (And how does this relate to the >> value returned by crypto_ahash_reqsize()?) The closest clue I can find >> is this: >> >> crypto_init_shash_ops_async() does: >> crt->reqsize = sizeof(struct shash_desc) + crypto_shash_descsize(shash); >> >> and that gets called from crypto_ahash_init_tfm(), so if it starts >> with the above reqsize and adds to it with a call to >> crypto_ahash_set_reqsize() later, we'll have that maximum? >> >> So, do I want to calculate this answer as: >> >> sizeof(struct shash_desc) + max(shash descsize) + max(ahash-sync reqsize) ? >> 16 + 360 + 0 > > I arrived at the same number, looking at all the sizes in shash, > The largest I found are sha3_state (360 bytes) and s390_sha_ctx > (336 bytes), everything else is way smaller. Excellent. Thanks for double-checking this. :) > >> It's 0 above because if I look at all the callers of >> crypto_ahash_set_reqsize() that do wrapping, all are ASYNC. >> >> So, should this really just be 376? Where is best to validate this >> size, as it seems checking in crypto_ahash_set_reqsize() is >> inappropriate? > > How about crypto_init_shash_ops_async()? Ah yes, that looks good. Nice find! After my ahash to shash conversions, only ccm is left as an ahash user, since it actually uses sg. But with the hard-coded value reduced to 376, this doesn't trip the frame warnings any more. :) I'll send an updated series soon. -Kees -- Kees Cook Pixel Security -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
