Hi Tyler,
On 07/04/2019 03:58 PM, Tyler Hicks wrote:
Hey Mimi!
On 2019-07-04 11:46:41, Mimi Zohar wrote:
Hi Jarkko,
On Thu, 2019-07-04 at 07:48 -0400, Mimi Zohar wrote:
On Thu, 2019-07-04 at 13:28 +0200, Roberto Sassu wrote:
On 7/4/2019 12:03 PM, Jarkko Sakkinen wrote:
On Mon, 2019-07-01 at 15:15 +0200, Michal Suchanek wrote:
This reverts commit 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400 to avoid
following crash:
Thank you. I think this the right choice for the moment. I fixed
a trivial checkpatch.pl error and added the mandatory tags. Can
you check quickly v2 (just posted)?
I already made it available in my master and next.
Could you please wait few days? I would prefer to fix this issue instead
of reverting the whole patch.
Nayna posted a patch late yesterday titled "tpm: fixes uninitialized
allocated banks for IBM vtpm driver", which addresses this bug.
Now with my review, and with Sachin Sant's and Michal Suchánek
testing, instead of reverting this patch could you pick up Nayna's
patch instead?
It looks to me like the revert would also fix a bug that is keeping the
eCryptfs module from loading when the TPM is in an "inactive" state:
https://bugzilla.kernel.org/show_bug.cgi?id=203953
I just noticed that it was recently discussed here, too:
https://lore.kernel.org/linux-integrity/1562244125.6165.95.camel@xxxxxxxxxxxxx/T/#t
I believe that the revert would fix it because the call to
init_digests()/tpm_get_random() would no longer be in the path of
loading ecryptfs.ko (which depends on encrypted-keys.ko, which depends
on trusted.ko).
If the revert isn't used, we'll need a different fix for bug 203953. It
should be an easy fix but I don't want it to be forgotten.
I think if TPM is inactive/disabled, it needs to be handled during
tpm_chip_register() itself. However, probably that needs more analysis
and discussion. For now, in context of the trusted.ko module, it seems
init_trusted() should "put_device", but continue even if init_digests()
fails, that will fix the issue.
Thanks & Regards,
- Nayna
