Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1606959
| From | Ken Goldman <kgoldman@us.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces |
| Date | 2017-03-22 21:20 +0100 |
| Message-ID | <tnUTE-85w-29@gated-at.bofh.it> (permalink) |
| References | <tbzUB-2oT-3@gated-at.bofh.it> <tbzUC-2oT-29@gated-at.bofh.it> <tdnmi-6iG-29@gated-at.bofh.it> <tdJ3s-5dB-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
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
csiph-web