All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ken Goldman <kgoldman-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: TPM 2.0 RM flushcontext returning bad address
Date: Wed, 11 Jan 2017 14:43:50 -0500	[thread overview]
Message-ID: <o561te$39p$1@blaine.gmane.org> (raw)
In-Reply-To: <20170110224225.GA5451-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

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

  parent reply	other threads:[~2017-01-11 19:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 20:01 TPM 2.0 RM flushcontext Ken Goldman
2017-01-10 20:08 ` Jason Gunthorpe
     [not found]   ` <20170110200803.GB5102-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-10 22:31     ` TPM 2.0 RM flushcontext returning bad address Ken Goldman
2017-01-10 22:42       ` Jason Gunthorpe
     [not found]         ` <20170110224225.GA5451-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-01-11 11:38           ` Jarkko Sakkinen
2017-01-11 19:43           ` Ken Goldman [this message]
2017-01-11 19:56             ` James Bottomley
     [not found]               ` <1484164614.2509.31.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-01-11 20:29                 ` Ken Goldman
2017-01-14 16:45                 ` James Bottomley
     [not found]                   ` <1484412351.2424.7.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-01-14 18:19                     ` Ken Goldman
2017-01-14 18:32                       ` James Bottomley
2017-01-11 21:55             ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='o561te$39p$1@blaine.gmane.org' \
    --to=kgoldman-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.