luks-seal: tpm2_evictcontrol fails if there is nothing to evict

[v3rm0n]

Not sure what to do about this:

Sealing secret with TPM
Installing sealed secret into TPM
WARNING:esys:src/tss2-esys/api/Esys_ReadPublic.c:320:Esys_ReadPublic_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/esys_tr.c:231:Esys_TR_FromTPMPublic_Finish() Error ReadPublic ErrorCode (0x0000018b) 
ERROR:esys:src/tss2-esys/esys_tr.c:321:Esys_TR_FromTPMPublic() Error TR FromTPMPublic ErrorCode (0x0000018b) 
ERROR: Esys_TR_FromTPMPublic(0x18B) - tpm:handle(1):the handle is not correct for the use
ERROR:esys:src/tss2-esys/esys_tr.c:357:Esys_TR_Close() Error: Esys handle does not exist (70018). 
ERROR: Esys_TR_Close(0x70018) - esapi:0x18
ERROR: Unable to run tpm2_evictcontrol
Unable to remove old TPM key context 0x81000000
/tmp/tmp.W3zoRYMEZ3: Unmounting

[osresearch]

Have you ever sealed a secret into the TPM? If this is your first time ever doing so, I think the script is assuming there is one to evict and that is causing a problem if there isn't one already there... Can you try making this change:

diff --git a/sbin/safeboot b/sbin/safeboot
index 629240c..61f1a64 100755
--- a/sbin/safeboot
+++ b/sbin/safeboot
@@ -429,7 +429,7 @@ luks-seal() {
 	tpm2_evictcontrol \
 		--object-context "$HANDLE" \
 		>> /tmp/tpm.log \
-	|| die "Unable to remove old TPM key context $HANDLE"
+	|| warn "Unable to remove old TPM key context $HANDLE"
 
 	tpm2_evictcontrol \
 		--object-context "$TMP/key.context" \

[v3rm0n]

TPM was cleared before this. Using warn instead of die helped and I was able to finish the process successfully, thanks!

[osresearch]

It might be safe to change the die to a warn in the general case, since the next call to persist the object will die if it fails. Except that I don't see a way to say "persist this object at this handle"; the tpm2 API is so baroque that it is very difficult to tell how you're supposed to do some of these things.

[tomoveu]

This is indeed strange and the TPM2 Spec is a horror show, so @osresearch I know how you feel.

The only thing that makes impression on me is the fact evictcontrol is called to eveict an object at $HANDLE, but on the second call no particular $HANDLE is specified for installing your secret. This means that evictcontrol would take the first empty handle. But there is no guarantee that wil be exactly $HANDLE cleared in the first step, so I am bit confused. Is this intentional and why?

@v3rm0n could you please run
$ tpm2_getcap handles-nv-index
and share the output with us?

[osresearch]

It's the hoped-for behavior, based on what I observed on my thinkpad since $HANDLE is the (supposed to be) the lowest value. tpm2_evictcontrol only takes a single context argument, so either the 0x8100000 handle value or the file can be specified. Is there a way to ensure that the correct handle is used always?

[tomoveu]

@osresearch yes, unless they changed its parameters, again. This was mentioned in our call this week. Params on tpm2-tools change so often it is almost hell.

Anyways, you should be able to pass -c for context and and then the $HANDLE as additional argument like this

tpm2_evictcontrol -c primary.ctx 0x81010002

I am seeing it is still true in the latest man page, so I hope it must be true - https://github.com/tpm2-software/tpm2-tools/blob/master/man/tpm2_evictcontrol.1.md

Then, could you please tell me where you initialize $HANDLE to the lowest possible value and consider $ tpm2_getcap handles-nv-index could surprise you for the handle indexes.

[v3rm0n]

➜  ~ sudo tpm2_getcap handles-nv-index
- 0x1C00002
- 0x1C0000A
- 0x1C10102
- 0x1C10103
- 0x1C10104

[osresearch]

The LUKS sealed keys are no longer stored in the TPM, but in the initrd instead. They do not change between signed kernels as part of #57, which eliminates the need for the handle tracking.