tpm2-tools-2.1.0 and tpm_server (ibmtpm974) #469
Comments
tomaszpr
changed the title
|
Hi Tomasz, |
|
Any resource manager visualizes handles between clients, so it's possible that two clients have the same handle, but the RM is routing them differently under-the-covers. With that said, your issues arise on 974 and not 532. Does the tpm2-tools test suite pass if run against 974? Looking at this, I am not really sure what the issue is, @flihp any comments? |
|
Hi Tomasz,
I'm trimming this down a bit to focus on the relevant stuff:
On Thu, 2017-09-07 at 03:05 -0700, tomaszpr wrote:
CreatePrimary Succeed ! Handle: 0x800000ff
Strange, I get twice the same Handle: 0x800000ff for both primary
keys.
This is expected behavior. The tabrmd is recycling handles that are
freed up after it unloads the objects you're using.
But I want to show something different.
After first execute of this command:
./tpm2_create -c po_own.ctx -P objectpass -K subobjectpass -g 0x000b
-G 0x0001 -o key.pub -O key.priv -T tabrmd -V
I get:
contextParentFile = po_own.ctx
nameAlg = 0x000b
type = 0x0001
ObjectAttribute: 0x00060072
Create Object Failed ! ErrorCode: 0x922
But when I retry it succed, the same call, the same arguments, no
other calls between them.
Funny enough if you decode this response code (using the tpm2_rc_decode
tool from the tools project) it decodes to TPM_RC_RETRY. So retrying is
the right thing. Think of this as an analog to an interrupted
systemcall returning EINTR.
In a pending PR for the TSS I've added a macro to our test harness
that's similar to the GNU TEMP_FAILURE_RETRY macro:
tpm2-software/tpm2-tss@8d2cdf21b159035746c1
5d3fe3536d2c37d92873#diff-e4a2320e253ceed5791461849737710dR39
Would be interested to know if this works for you too. Might be
something we want to expose through the TSS headers.
Regards,
Philip
|
|
Sorry, email interface borked up my link. The relevant macro is here: tpm2-software/tpm2-tss@8d2cdf2#diff-e4a2320e253ceed5791461849737710dR39 |
|
We might want to consider wrapping the tool invocations in the retry macro... |
|
I'm considering having the tabrmd retry for the caller. Not sure if this will cause more problems than it solves though. |
|
If you do it in abrmd, I would need to add it to the device TCTI as well so it's consistent. What do you think about that? |
|
@williamcroberts If the retry logic is in the abrmd, then I think that for consistency it should be in the kernel resource manager and not in the device TCTI. In the same way that the device TCTI doesn't do context swapping and that is left to the kernel RM, it shouldn't abstract from the TPM returning a TPM_RC_RETRY code IMHO. IOW, the device TCTI (without the in-kernel RM) should expose a "raw" (what's the correct term for this?) access to the TPM. |
|
What about if your using /dev/tpm0 and not /dev/tpmrm0?
From: Javier Martinez Canillas [mailto:notifications@github.com]
Sent: Friday, September 8, 2017 11:31 AM
To: 01org/tpm2-tools <tpm2-tools@noreply.github.com>
Cc: Roberts, William C <william.c.roberts@intel.com>; Mention <mention@noreply.github.com>
Subject: Re: [01org/tpm2-tools] tpm2-tools-2.1.0 and tpm_server (ibmtpm974) (#469)
@williamcroberts<https://github.com/williamcroberts> If the retry logic is in the abrmd, then I think that for consistency it should be in the kernel resource manager and not in the device TCTI.
In the same way that the device TCTI doesn't do context swapping and that is left to the kernel RM, it shouldn't abstract from the TPM returning a TPM_RC_RETRY code IMHO.
IOW, the device TCTI (without the in-kernel RM) should expose a "raw" (what's the correct term for this?) access to the TPM.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#469 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQ7bBw6mzAJrrEuI6JblnDe65EDddsSXks5sgYfogaJpZM4PPleT>.
|
|
@williamcroberts that's precisely my point. There's already a difference between using /dev/tpm0 and /dev/tpmrm0. With /dev/tpm0, you get 0x902 (TPM_RC_OBJECT_MEMORY) errors when creating more than TPM_PT_HR_TRANSIENT_MIN objects due the TPM running out of space for them. But that doesn't happen when having a resource manager (either /dev/tpmrm0 or tabrmd). So in the same way, if tabrmd will abstract users about the 0x922 (TPM_RC_RETRY) error and just retry, I think that's fair to expect the same when using /dev/tpmrm0. But that's not necessarily true when using /dev/tpm0, since just like the device TCTI doesn't handle the TPM_RC_OBJECT_MEMORY error, I don't think is its responsibility to deal with TPM_RC_RETRY. |
@tstruk Hi Tadeusz! Thank you for answering.
Do yout think than use of tpm_server -rm will change something ? |
Right, there should be some way to talk to the TPM without anything interfering with the commands/responses being sent.
Having a central implementation that just does "the right thing", so that not every application needs to contain the same logic, would be nice. But is the resource manager the correct place? Retrying a command has nothing to do with resources, and I'd guess for this reason alone it might be rejected for the kernel RM (which aims for a rather minimalistic implementation). Also, what is the correct way to handle TPM_RC_RETRY? I only found the description "the TPM was not able to start the command" in the specification, but no further information. Can you simply send the same byte stream again (even when using sessions/nonces)? What if you receive the same error? Do you add a small delay? When do you give up? There are a couple more response codes that sound like they could be handled in the same way: TPM_RC_YIELDED, TPM_RC_TESTING, TPM_RC_NV_RATE |
|
@webmeister I don't think any retry code is appropriate for inside the resource manager itself and should be handled at the application level. |
|
Right, I didn't say that the retry logic should be in the resource manager (I still lack understanding about the resource manager spec to have an informed opinion). What I said is that if the retry logic will be in the D-Bus tabrmd (as IIUC @flihp suggested), then for consistency it should be in the in-kernel resource manager and not in the device TCTI. But I think is OK if that logic is both in the tabrmd and device TCTI libraries. |
|
@martinezjavier than we agree. I don't think the RMs should have retry logic. @flihp? |
But why simulator returns retry ? |
|
On 09/10/2017 11:23 PM, tomaszpr wrote:
@tstruk <https://github.com/tstruk> Hi Tadeusz! Thank you for answering.
Before each retest I do that:
* stop tpm2-abrmd,
* stop tpm_server,
* remove NVChip file,
* start tpm_server,
* start tpm2-abrmd.
Do yout think than use of tpm_server -rm will change something ?
I think that removing of NVChip give the same effect. Or I'm wrong ?
Hi Tomasz,
Yes, you are right. Removing NVChip file and restarting tpm_server is
equivalent to restarting tpm_server with -rm option. Just thought that
it will help for the 0x902 (out of memory for object contexts) error.
I usually get this error when I forget clean the NV store.
Thanks,
--
Tadeusz
|
|
Hi, Repeated: When I repeat this test from the begining without 'objectpass', the test succeed. It doesn't happen with: |
|
I wonder what would happen if you tried it with: |
Run the ci tests against the lates software tpm simulator, version 974. Fixes: tpm2-software#469 Signed-off-by: William Roberts <william.c.roberts@intel.com>
|
Blocked on: tpm2-software/tpm2-abrmd#224 |
|
Doing this in the TSS would be nice, this way I don't have to wrap my tss calls in something like a temp_failure_retry ala glibc macro. |
|
I ran into this again while working on #586. Since integrating the retry logic in the stack is a bit intrusive I'm polling the TCG TSS WG members for their thoughts. While I'm waitnig on that my plan is to implement the |
|
There's a PR including this work in #585 |
|
#585 contained a fix for this & was merged yesterday |
There are some errors on debian when I use:
tpm_server (ibmtpm974)
tpm2-tss-1.2.0
tpm2-tools-2.1.0
tpm2-abrmd-1.1.1
NVchip is deleted
tpm_server is running:
TPM command server listening on port 2321
Platform server listening on port 2322
tpm2-abrmd is running:
./tpm2-abrmd -t socketfrom tpm_server I get:
Client accepted
Client accepted
when I try to init TPM simulator and create keys I get:
Strange, I get twice the same Handle: 0x800000ff for both primary keys.
But I want to show something different.
After first execute of this command:
./tpm2_create -c po_own.ctx -P objectpass -K subobjectpass -g 0x000b -G 0x0001 -o key.pub -O key.priv -T tabrmd -VI get:
But when I retry it succed, the same call, the same arguments, no other calls between them.
As I found it happens with ibmtpm974. There is no problem with 532.
But on the 532 is the same problem with the same Handle: 0x800000ff after tpm2_createprimary
When I don't use tpm2-abrmd it's working in another way.
When I use:
tpm_server (ibmtpm974)
tpm2-tss-1.2.0
tpm2-tools-2.1.0
Success! Different handles, but :
Command repeated:
When I use tpm_server ver.532, error happens in another place:
tpm_server (ibmtpm532)
tpm2-tss-1.2.0
tpm2-tools-2.1.0
Now it is ok, but:
I noticed that when tpm2-abrmd is used, there are the same handles returned for different keys.
tpm_server (ibmtpm974)
tpm2-tss-1.2.0
tpm2-tools-2.1.0
tpm2-abrmd-1.1.1
Handle repeated!
And ...
the same key, second chanse (issue described before):
second key:
but Handle repeated!
So, conclusion is:
when tpm2-abrmd is used, it returns the same handles for different keys,
and it works in another way when tpm2-abrmd is used and when is not used.
Thanks in advance!
Best regards,
Tomek
The text was updated successfully, but these errors were encountered: