On Thu, 2018-05-31 at 14:06 -0700, Matthew Garrett wrote: > On Thu, May 31, 2018 at 1:32 PM Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, 2018-05-31 at 13:07 -0700, Matthew Garrett wrote: > > > On Thu, May 31, 2018 at 12:55 PM Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Thu, 2018-05-31 at 12:30 -0700, Matthew Garrett wrote: > > > > > Cool. Mimi, does this satisfy your concerns with the non-SHA1 patch? > > > > > > > > This should be posted as a separate patch, with the appropriate > > > > "Fixes" commit info. It requires an ack from Herbert Xu. > > > > > > The non-sha1 patch doesn't seem to be in -next at the moment - should > > > I wait for you to merge that so I can add the fixes tag? > > > > The problem exists prior to the non-sha1 patch, but could have been > > resolved differently for only sha1 (eg. Kconfig requiring sha1). The > > non-sha1 patch requires a different solution. > > EVM looks like it SELECTs CONFIG_SHA1, so I /think/ it should be ok > before that patch? According to Junwen, with CONFIG_TRUSTED_KEYS enabled the HMAC and SHA1 are allocated at __init. The locking problem occurs when CONFIG_TRUSTED_KEYS is not enabled. His solution would have been to move the crypto_alloc_shash() in EVM to an __init function. Mimi
