Re: [openssl-tpm2-engine] [PATCH v2 1/8] tss: Fix handling of TPM_RH_NULL in intel-tss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2024-08-05 at 00:28 +0300, Jarkko Sakkinen wrote:
[...]
> > --- a/src/include/intel-tss.h
> > +++ b/src/include/intel-tss.h
> > @@ -251,14 +251,6 @@ intel_sess_helper(TSS_CONTEXT *tssContext,
> > TPM_HANDLE auth, TPMA_SESSION flags)
> >                                   TPMA_SESSION_CONTINUESESSION |
> > flags);
> >  }
> >  
> > -static inline TPM_HANDLE
> > -intel_handle(TPM_HANDLE h)
> > -{
> > -       if (h == 0)
> > -               return ESYS_TR_NONE;
> > -       return h;
> > -}
> > -
> >  static inline void
> >  TSS_Delete(TSS_CONTEXT *tssContext)
> >  {
> > @@ -937,8 +929,10 @@ tpm2_CreatePrimary(TSS_CONTEXT *tssContext,
> > TPM_HANDLE primaryHandle,
> >         TPM2B_PUBLIC *opub;
> >         TPM_RC rc;
> >  
> > -       /* FIXME will generate wrong value for NULL hierarchy */
> > -       primaryHandle = intel_handle(primaryHandle);
> > +
> > +       /* TPM_RH_NULL is mapped to ESYS_TR_NONE, which won't work
> > here */
> > +       if (primaryHandle == TPM_RH_NULL)
> > +               primaryHandle = INT_TPM_RH_NULL;
> >  
> >         outsideInfo.size = 0;
> >         creationPcr.count = 0;
> > @@ -993,9 +987,7 @@ tpm2_StartAuthSession(TSS_CONTEXT *tssContext,
> > TPM_HANDLE tpmKey,
> >                       TPM_HANDLE *sessionHandle,
> >                       const char *bindPassword)
> >  {
> > -       bind = intel_handle(bind);
> > -       tpmKey = intel_handle(tpmKey);
> > -       if (bind != ESYS_TR_NONE)
> > +       if (bind != TPM_RH_NULL)
> >                 intel_auth_helper(tssContext, bind, bindPassword);
> 
> Not blaming the patch but just have hard time coping this.
> 
> The most basic question is probably this: what is the application for
> INT_TPM_RH_NULL?

Ah, well, it turns out that the Intel TSS also isn't very performant
and part of the performance loss is using a memory database for
translating external TPM objects into internal ones.  Some of the
performance can be recovered by not doing this.

It turns out that the engine code never uses volatile external handles,
so the switch from volatile internal -> external and vice versa (which
occurs on load followed by key operation) was eliminated and the code
uses internal representation for volatile handles and external
representation for all other handles.  This scheme worked fine until
non-volatile key indexes were introduced and then it broke down a bit.
It would be logically very nice to redo the internal representation to
be entirely contained within the intel tss shim, but then that would
reintroduce the performance problem (although on the other hand, the
Intel TSS is still twice as slow as the IBM TSS so perhaps this
wouldn't be such a huge addition).

Regards,

James





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux