tpm2_load fails (Load Object Failed ! ErrorCode: 0x902) when using the device TCTI

[martinezjavier]

I'm testing latest tpm2.0-tools on a Lenovo Thinkpad X1 Carbon (4th gen) and its Intel PTT firmware based TPM2.0. The test_tpm2_unseal.sh fails when using the device TCTI, the issue happens when trying to load an object into the TPM:

$ ./configure --with-tcti-socket=no --with-tcti-tabrmd=no
...
checking for TCTI_DEV... yes

$ ./test/system/test_tpm2_unseal.sh
nameAlg = 0x0004
type = 0x0001
contextFile = context.p_0x0004_0x0001

CreatePrimary Succeed ! Handle: 0x80000000

nameAlg = 0x000b
type = 0x0008
inSensitive.t.sensitive.data.t.size = 9
contextParentFile = context.p_0x0004_0x0001
ObjectAttribute: 0x00000052

Create Object Succeed !
contextParentFile = context.p_0x0004_0x0001
contextFile = ctx_load_out_0x0004_0x0001-0x000B_0x0008

Load Object Failed ! ErrorCode: 0x902

load fail, please check the environment or parameters!

When decoding the error code, I see that is TPM_RC_OBJECT_MEMORY:

$ tpm2_rc_decode 0x902
error layer
  hex: 0x0
  identifier: TSS2_TPM_ERROR_LEVEL
  description: Error produced by the TPM
format 0 warning code
  hex: 0x02
  name: TPM_RC_OBJECT_MEMORY
  description: out of memory for object contexts

It works though when using the TPM2 Access Broker & Resource Manager TCTI instead:

$ ./configure --with-tcti-socket=no --with-tcti-device=no
...
checking for TCTI_TABRMD... yes

$ sudo systemctl start tpm2-abrmd

$ ./test/system/test_tpm2_unseal.sh
nameAlg = 0x0004
type = 0x0001
contextFile = context.p_0x0004_0x0001

CreatePrimary Succeed ! Handle: 0x800000ff

nameAlg = 0x000b
type = 0x0008
inSensitive.t.sensitive.data.t.size = 9
contextParentFile = context.p_0x0004_0x0001
ObjectAttribute: 0x00000052

Create Object Succeed !
contextParentFile = context.p_0x0004_0x0001
contextFile = ctx_load_out_0x0004_0x0001-0x000B_0x0008

Load succ.
LoadedHandle: 0x80000100

$ cat usl_ctx_load_out_0x0004_0x0001-0x000B_0x0008
        12345678

I noticed the error comes from tss2_tcti_receive() called by Tss2_Sys_ExecuteFinish() in TPM2.0-TSS/blob/master/sysapi/sysapi/execute.c. The tss2_tcti_receive() function returns TSS2_RC_SUCCESS but SYS_CONTEXT->rsp_header.rsp_code is set to TPM_RC_OBJECT_MEMORY.

Tested with both the Fedora 26 tpm2-tss-1.0-3.fc26 package and building latest TPM2.0-TSS from source.

NOTE: I changed the test to use the endorsement hierarchy instead of the platform one, since I faced the same problem mentioned at issue #255.

[crogers1]

The maximum number of loaded handles at any given time is 3, defined in the sapi of TPM2.0-TSS. At a high level, the resourcemanager is responsible for maintaining all of your handles and swapping them in and out in order to avoid hitting TPM_RC_OBJECT_MEMORY. When you run this test without the resourcemanager, you become responsible for flushing the handles when you're done with them.

[martinezjavier]

@crogers1 ah, right. Thanks a lot for your explanation. I'll close this issue then since is the expected behavior, sorry for the noise.

I think it would be nice to have a set of tests to run against the TPM device directly, but that's an unrelated conversation.

[martinezjavier]

For completeness, if someone faces the same issue and also forgets that the TPM can only load TPM_PT_HR_TRANSIENT_MIN transient objects, what I did was to use the new TPM2 in-kernel resource manager that just landed in Linux v4.12-rc1.

With that, I was able to use the tpm2.0-tools commands with the device TCTI to load and unseal data:

$ export TPM2TOOLS_TCTI_NAME=device
$ export TPM2TOOLS_DEVICE_FILE=/dev/tpmrm0

$ echo foobar > secret.data

$ tpm2_takeownership -c
$ tpm2_createprimary -A e -g 0x0004 -G 0x0001 -C context.p_0x0004_0x0001
$ tpm2_create -g 0x000B -G 0x0008 -o opu_0x000B_0x0008 -O opr_0x000B_0x0008  -I secret.data -c context.p_0x0004_0x0001
$ tpm2_load -c context.p_0x0004_0x0001  -u opu_0x000B_0x0008  -r opr_0x000B_0x0008 -n name.load_0x0004_0x0001-0x000B_0x0008 -C ctx_load_out_0x0004_0x0001-0x000B_0x0008
$ tpm2_unseal -c ctx_load_out_0x0004_0x0001-0x000B_0x0008 -o usl_ctx_load_out_0x0004_0x0001-0x000B_0x0008

[liuqun]

The TPM2 in-kernel resource manager is available now, see: https://github.com/torvalds/linux/commits/master/drivers/char/tpm/tpmrm-dev.c

[martinezjavier]

@liuqun yes. As mentioned, I've been using it since v4.12-rc1 that's when the support landed in mainline.

[jhand2]

@martinezjavier If you know the answer to this, if the damage is already done, how to I clear NVRAM and get my TPM back in a working state? I've tried tpm2_flushcontext with -s, -l, and -t options. But still with every command I run, I get "out of memory for object contexts" event when using tabrmd or in-kernel rm

[williamcroberts]

-t and -l and -s will only flush the transient, loaded and active sessions respectively. Did you make a bunch of persistent objects? Everything else would go away on TPM reboot (ie power off and on), thus I think the only way you could be in this state is if everything is persistent object.

You can try to flush specific objects out by handle, flush everything reported by:

./tpm2_getcap -c handles-transient
./tpm2_getcap -c handles-persistent

I'd be interested in the output of those commands before you run,

tpm2_flushcontext -c=<handle>

Note that on tip-of-master post ESAPI cange, transient objects need to be referred to by the context file provided by tpm2_load. Again, transient objects will go away on reboot, so they are not really of consequence.

If this doesn't work, i'd look at your NV space and see if thats full and somehow fueling into this situation.
After that, if clearing NV doesn't do the trick I'd see if their is a hard reset for the TPM, usually a BIOS setting from what I understand. Iv'e never actually done it.