Messages in this thread | | | Date | Wed, 20 Jul 2016 15:13:32 -0600 | From | Jason Gunthorpe <> | Subject | Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted() |
| |
On Wed, Jul 20, 2016 at 11:53:14PM +0300, Jarkko Sakkinen wrote:
> The only use cases I see at the moment for it work this way: > > 1. Call tpm_try_get_ops. > 2. Send a TPM command. > 3. Call tpm_put_ops.
Right, but that is just a reflection of what the in kernel users are doing today, not necessarily what they should be doing.
We should not break the put/get semantics..
> I did not find any other form of use. The only use is to make sure that > there are no transactions running before the ops are cleared. Or did I > overlook something perhaps?
The put/get is intended to allow a kapi user to hold a ref to tpm without it geting destroyed. It is not intended to be an exclusive lock.
> Trusted key unseal operation with TPM2 is broken into two operations: > > 1. Load the given key blob. > 2. Unseal the data. > > Without locking and unlocking mutex only once there is a race condition.
Well, the race condition is fundamentally because we don't have key virtualization in the kernel :|
Those sorts of compound ops should hold the tpm_mutex manually, not through the get_ops scheme.
Jason
| |