Re: TPM 2.0 RM flushcontext returning bad address

[James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>]

On Wed, 2017-01-11 at 14:43 -0500, Ken Goldman wrote:
> On 1/10/2017 5:42 PM, Jason Gunthorpe wrote:
> > On Tue, Jan 10, 2017 at 05:31:45PM -0500, Ken Goldman wrote:
> > > On 1/10/2017 3:08 PM, Jason Gunthorpe wrote:
> > > > > 4 - Is a write() error desirable?  I think the application 
> > > > > would prefer a TPM formatted response like TPM_RC_VALUE.
> > 
> > .. and we have to define what all the possible errnos mean. 
> > Defining EBADF to mean 'RM found invalid handle in message' is 
> > probably sane.
> > 
> > > 2 - What's the TSS supposed to do with it?  I can return some 
> > > generic "problem in the TPM device driver".
> > 
> > Depends on the midlayer I suppose. If it supports string error
> > formatting it could decode EBADF to the string 'RM found invalid
> > handle in message' for instance.
> 
> I'll try again with additional reasons:
> 
> - As much as possible, the RM should be transparent to the 
> application. Returning a TPM return code in one case and a write() 
> bad address in the other violates that.
> 
> - The TPM spec says to return TPM_RC_HANDLE.  This is what 
> application developers will expect when they use an invalid handle.
> 
> - (No flames, please)  I asked Microsoft what they do in their 
> resource manager.  They return TPM_RC_HANDLE.
> 
> - The TPM encodes information in the return code.  In this case 
> 0x01c4 says that parameter 1 is bad.  Returning an errno is a lose of
> valuable debug information.
> 
> - If you repurpose Bad Address to mean an invalid handle, what 
> happens when there is really a bad address?
> 
> - EFAULT (bad address) is misleading.  A TPM handle is not an
> address.
> 
> - EBADF (bad file number) seems even more misleading.  What file?
> 
> - It's misleading.  A write() error should mean that the write to the
> TPM failed.  In this case, the RM didn't write, but says the write()
> failed.
> 
> - The "midlayer" is the lowest layer of the TSS, where it's writing 
> raw byte streams.  It has no idea that there's a handle in the 
> stream, and replacing the error code is awkward.
> 
> - Libraries by default do not print strings.
> 
> - There's no guarantee that EBADF means "invalid handle".  I counted 
> 17 EFAULT uses, most low level driver errors.  The TSS could mislead 
> the user.
> 
> Solution:
> 
> I suspect that the RM could just code:
> 
> 	if (can't map the transient handle for this connection)
> 		map it to TPM_RH_NULL
> 
> and let the TPM do the rest.

I'm playing with adding session based handles to the RM now.  What I
find is that there's no escape from interpreting TPM2_FlushContext
because we need to know if we can release a session resource and we
can't rely on the continuation parameter alone.  Given this problem, it
looks like we have no choice but to intercept TPM2_FlushContext and
emulate its execution, so we're going to have to manufacture at least
some TPM return codes within the kernel.  Once we start down this path,
it's probably fairly easy to add for the other RM returns.

James



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi