On Mon, Sep 09, 2019 at 05:28:08PM +0100, Jarkko Sakkinen wrote:
On Sat, Sep 07, 2019 at 06:04:48PM -0400, Sasha Levin wrote:
On Sat, Sep 07, 2019 at 09:55:18PM +0300, Jarkko Sakkinen wrote:
On Tue, 2019-09-03 at 15:43 -0400, Sasha Levin wrote:
Right. I gave a go at backporting a few patches and this happens to be one of them. It will be a while before it goes in a stable tree (probably way after after LPC).
It *semantically* depends on
db4d8cb9c9f2 ("tpm: use tpm_try_get_ops() in tpm-sysfs.c.")
I.e. can cause crashes without the above patch. As a code change your patch is fine but it needs the above patch backported to work in stable manner.
So... either I can backport that one (because ultimately I have responsibility to do that as the maintainer) but if you want to finish this one that is what you need to backport in addition and then it should be fine.
If you're ok with the backport of this commit, I can just add db4d8cb9c9f2 on top.
Sure, I've already gave my promise to do that :-)
I ended up with:
db4d8cb9c9f2 tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations 2677ca98ae37 tpm: use tpm_try_get_ops() in tpm-sysfs.c. da379f3c1db0 tpm: migrate pubek_show to struct tpm_buf
Since some time has passed I'l just restate that the reason for backporting 2677ca98ae37 was that tpm_class_shutdown() could pull carpet under the TPM 1.2 code. tpm_try_get_ops() makes sure that read lock is taken and chip->ops is not NULL if it successfully returns.
Still need to test the patches with TPM 1.2 hardware before I can send them.
/Jarkko