TPM 2.0 RM flushcontext

TPM 2.0 RM flushcontext

[Ken Goldman]

1 - Is this the correct place to post potential RM issues?

2 - Here's my test case:

test0: primary key 80ffffff
test0: signing key 0 80fffffe
test0: signing key 1 80fffffd
test0: session 02000000
test0: sign with 02000000 80fffffe
test0: sign with 02000000 80fffffd
	listTransientObjects: 80000000
	listTransientObjects: 80000001
	listTransientObjects: 80000002
test0: flush 80fffffe
rmtest: failed, rc 000001c4
TPM_RC_VALUE - value is out of range or is not correct for the context 
Parameter number 1

The signing key at 80fffffe exists, because I can sign with it. 
However, the flush fails.

3 - I thought that perhaps the RM was not handling flushcontext yet. 
When I tried to flush 80000002, the write() fails.

TSS_Dev_SendCommand: write error 14 Bad address

So it seems that the RM is doing something with the flushcontext handle.

4 - Is a write() error desirable?  I think the application would prefer 
a TPM formatted response like TPM_RC_VALUE.

Would it be easy to hard code this response for any handle mapping error?

80 01 00 00 00 0a 00 00 00 c4




------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext

[Jason Gunthorpe]

On Tue, Jan 10, 2017 at 03:01:16PM -0500, Ken Goldman wrote:
> 4 - Is a write() error desirable?  I think the application would prefer 
> a TPM formatted response like TPM_RC_VALUE.

IMHO, I prefer the write errno, but we need to clearly define what our
errnos means. Errnos used by RM should not overlap with errnos from
other parts of our kernel stack.

This makes it clear the kernel is source of the error, not the physical TPM.

Jason

------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[Ken Goldman]

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.
>
 >
> IMHO, I prefer the write errno, but we need to clearly define what our
> errnos means. Errnos used by RM should not overlap with errnos from
> other parts of our kernel stack.
>
> This makes it clear the kernel is source of the error, not the physical TPM.

Except that the kernel is clearly not the source of the error.  The user 
application tried to flush a handle and specified the wrong handle number.

"write error" sounds like a write error, but the TPMDD didn't actually
write anything.

"bad address" sounds like the kernel tried to access a bad address.  But 
it didn't access any address.

1 - I prefer an error that is meaningful to the user, and I think this 
one is very misleading.

2 - What's the TSS supposed to do with it?  I can return some generic 
"problem in the TPM device driver".

It's going to take a long time for the average user to realize that the 
"bad address" is actually a bad key handle.






------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[Jason Gunthorpe]

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.
> >
>  >
> > IMHO, I prefer the write errno, but we need to clearly define what our
> > errnos means. Errnos used by RM should not overlap with errnos from
> > other parts of our kernel stack.
> >
> > This makes it clear the kernel is source of the error, not the physical TPM.
> 
> Except that the kernel is clearly not the source of the error.  The user 
> application tried to flush a handle and specified the wrong handle number.
> 
> "write error" sounds like a write error, but the TPMDD didn't actually
> write anything.

We are probably going to be going to ioctl, so it would be an ioctl
error.

> "bad address" sounds like the kernel tried to access a bad address.  But 
> it didn't access any address.

.. 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.

Jason

------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[Jarkko Sakkinen]

On Tue, Jan 10, 2017 at 03:42:25PM -0700, 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.
> > >
> >  >
> > > IMHO, I prefer the write errno, but we need to clearly define what our
> > > errnos means. Errnos used by RM should not overlap with errnos from
> > > other parts of our kernel stack.
> > >
> > > This makes it clear the kernel is source of the error, not the physical TPM.
> > 
> > Except that the kernel is clearly not the source of the error.  The user 
> > application tried to flush a handle and specified the wrong handle number.
> > 
> > "write error" sounds like a write error, but the TPMDD didn't actually
> > write anything.
> 
> We are probably going to be going to ioctl, so it would be an ioctl
> error.
> 
> > "bad address" sounds like the kernel tried to access a bad address.  But 
> > it didn't access any address.
> 
> .. and we have to define what all the possible errnos mean. Defining
> EBADF to mean 'RM found invalid handle in message' is probably sane.

[x]

Works for me.

/Jarkko

------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[Ken Goldman]

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.








------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[James Bottomley]

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

Re: TPM 2.0 RM flushcontext returning bad address

[Ken Goldman]

On 1/11/2017 2:56 PM, James Bottomley wrote:

> 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.

If this helps:

FlushContext can have any handle (except permanent handles)

In addition:

Session - continue attribute false
Sequence - SequenceComplete, EventSequenceComplete

Manufacturing error codes in the kernel is one possibility. Another is 
to just map the unknown handle to TPM_RH_NULL and let the TPM do the rest.




------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[James Bottomley]

On Wed, 2017-01-11 at 11:56 -0800, James Bottomley wrote:
> 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.

The patch I posted

[PATCH] tpm: add session handles to the save and restore of the tpm2
space manager

Should fix all of this.  The code has to partially emulate
TPM2_FlushContext.  The emulation is

   1. If the handle type is not one we manage (transient, hmac or policy)
      send the command on to the TPM
   2. next, if the handle isn't currently in the RM table, manufacture a
      TPM_RC_HANDLE error and return it
   3. remove the handle from the RM table
   4. if the handle is transient, manufacture TPM_RC_SUCCESS and return it
   5. otherwise it's a session handle: flush it and return success.

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

Re: TPM 2.0 RM flushcontext returning bad address

[Ken Goldman]

On 1/14/2017 11:45 AM, James Bottomley wrote:
>
> Should fix all of this.  The code has to partially emulate
> TPM2_FlushContext.  The emulation is
>
>    1. If the handle type is not one we manage (transient, hmac or policy)
>       send the command on to the TPM
>    2. next, if the handle isn't currently in the RM table, manufacture a
>       TPM_RC_HANDLE error and return it
>    3. remove the handle from the RM table
>    4. if the handle is transient, manufacture TPM_RC_SUCCESS and return it
>    5. otherwise it's a session handle: flush it and return success.

This sounds right, assuming:

1 - The RM immediately context saves and then flushes any transient 
object that's created or loaded onto the TPM.

If you want a list of commands that load transient objects, let me know.

2 - Step 3 also implies deleting the saved context.



------------------------------------------------------------------------------
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

Re: TPM 2.0 RM flushcontext returning bad address

[James Bottomley]

On Sat, 2017-01-14 at 13:19 -0500, Ken Goldman wrote:
> On 1/14/2017 11:45 AM, James Bottomley wrote:
> > 
> > Should fix all of this.  The code has to partially emulate
> > TPM2_FlushContext.  The emulation is
> > 
> >    1. If the handle type is not one we manage (transient, hmac or
> > policy)
> >       send the command on to the TPM
> >    2. next, if the handle isn't currently in the RM table,
> > manufacture a
> >       TPM_RC_HANDLE error and return it
> >    3. remove the handle from the RM table
> >    4. if the handle is transient, manufacture TPM_RC_SUCCESS and
> > return it
> >    5. otherwise it's a session handle: flush it and return success.
> 
> This sounds right, assuming:
> 
> 1 - The RM immediately context saves and then flushes any transient 
> object that's created or loaded onto the TPM.

Yes, that's how the space code operates.  It saves every handle (well,
every policy, hmac or transient handle) after a command completes and
reloads them all before the next one.

> If you want a list of commands that load transient objects, let me
> know.

I think for simplicity, unless there's a severe performance impact, we
should stick with loading and saving everything for every command
rather than trying to be selective about  whether the command might
actually use any saved contexts.

> 2 - Step 3 also implies deleting the saved context.

Yes, that's what I meant by "remove" the function in the patch is tpm2
-space.c:tpm2_forget_session() It removes both the handle and the saved
context information for the now flushed session.

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

Re: TPM 2.0 RM flushcontext returning bad address

[Jason Gunthorpe]

On Wed, Jan 11, 2017 at 02:43:50PM -0500, Ken Goldman wrote:

> I'll try again with additional reasons:

There is *always* going to be the possibility of errnos from TPM
command excution, it has to be handled. You can quibble if certain
specific cases should be errno or TPM errors, but we can't release the
mid layer from coping with this.

> - 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.

Yes, we'd have to audit the kernel if we go this way. As I said, the
possible errnos from ioctl would have to be well defined and properly
implemented in the kernel.

> 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.

Sounds reasonable to me.

Jason

------------------------------------------------------------------------------
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