Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces
From: James Bottomley
Date: Wed Feb 22 2017 - 12:39:33 EST
On Tue, 2017-02-21 at 23:54 +0530, Nayna wrote:
> On 02/17/2017 12:55 AM, Jarkko Sakkinen wrote:
> > Added an ability to virtualize TPM commands into an isolated
> > context that we call a TPM space because the word context is
> > already heavily used in the TPM specification. Both the handle
> > areas and bodies (where necessary) are virtualized.
> > The mechanism works by adding a new parameter struct tpm_space to
> > the tpm_transmit() function. This new structure contains the list
> > of virtual handles and a buffer of page size (currently) for
> > backing storage.
> > When tpm_transmit() is called with a struct tpm_space instance it
> > will execute the following sequence:
> > 1. Take locks.
> > 2. Load transient objects from the backing storage by using
> > ContextLoad
> > and map virtual handles to physical handles.
> > 3. Perform the transaction.
> > 4. Save transient objects to backing storage by using ContextSave
> > and
> > map resulting physical handle to virtual handle if there is
> > such.
> > This commit does not implement virtualization support for hmac and
> > policy sessions.
> If I have understood discussions correctly, I assume, that kernel TPM
> operations will also be routed via RM. And I think that is not
> happening now with these patches.
> Am I missing something ?
Right at the moment the kernel use of tpm2 looks like
While it does this, there's no need for it to have a RM interface
because what it does between the acquisition and drop of the mutex
can't be seen by or have any effect on userspace (whether it uses the
RM or not). So currently, the question doesn't arise, which is the
situation you see.
When the kernel needs to use resources that persisted beyond it
dropping the chip->tpm_mutex (say using policy or audit sessions), then
it would need to become a customer of the RM.