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