Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1606959 > unrolled thread

Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces Ken Goldman <kgoldman@us.ibm.com> - 2017-03-22 21:20 +0100
    Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-03-23 17:00 +0100

#1606959 — Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces

On 2/22/2017 12:39 PM, James Bottomley wrote:
>
> Right at the moment the kernel use of tpm2 looks like
>
> acquire chip->tpm_mutex
> load key
> process key
> unload key
> release chip->tpm_mutex
>
> 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.

1 - This appears to depend on the RM not releasing the mutex until all 
objects are swapped out.  Correct?  Same for sessions?

2 - A startauthsession can cause a regap error.  Does the above depend 
on the RM doing early regapping so the RM won't see that error?

3 - There's also the problem where the TPM saved session slots 
(typically 64) are full.  My intuition is that the best solution is for 
the RM to reserve 3 slots for the kernel.

[toc] | [next] | [standalone]

#1607646

On Wed, Mar 22, 2017 at 04:09:21PM -0400, Ken Goldman wrote:
> On 2/22/2017 12:39 PM, James Bottomley wrote:
> > 
> > Right at the moment the kernel use of tpm2 looks like
> > 
> > acquire chip->tpm_mutex
> > load key
> > process key
> > unload key
> > release chip->tpm_mutex
> > 
> > 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.
> 
> 1 - This appears to depend on the RM not releasing the mutex until all
> objects are swapped out.  Correct?  Same for sessions?

Yes.

> 2 - A startauthsession can cause a regap error.  Does the above depend on
> the RM doing early regapping so the RM won't see that error?

We are not trying to resolve that for 4.12. It can happen.

> 3 - There's also the problem where the TPM saved session slots (typically
> 64) are full.  My intuition is that the best solution is for the RM to
> reserve 3 slots for the kernel.

Maybe but at the moment kernel does not use sessions.

/Jarkko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web