On Wed, Jan 11, 2023 at 6:31 AM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2023-01-11 at 17:49 +0530, Sughosh Ganu wrote: > > On Sat, 7 Jan 2023 at 04:43, William Roberts > > <bill.c.roberts@xxxxxxxxx> wrote: > [...] > > > tpm2_sessionconfig prints the raw handle for this purpose. I think > > > we added it when someone specifically needed the raw handle to > > > pass to the kernel. > > > > I tried getting the raw handle using the tpm2_sessionconfig command > > on the context file, and I did get the session handle. The session > > digest also matches the policy digest that was used at the time of > > the trusted key creation. However, when I pass the session handle > > value through the policyhandle parameter for the key loading > > operation, the unsealing fails. > > > > I run the following commands for the key load operation. > > > > # tpm2_startauthsession -S session.ctx --policy-session > > # tpm2_policypcr -S session.ctx -l sha256:10 > > # tpm2_sessionconfig session.ctx <--- Running this gives me the > > session handle. > > # keyctl add trusted kmk-trusted "load `cat kmk-trusted.blob` > > keyhandle=0x81000001 hash=sha256 policyhandle=0x03000000" @u > > > > [ 217.219048] tpm tpm0: A TPM error (2328) occurred unsealing > > Error 2328 is TPM_RC_REFERENCE_S0 - the 1st authorization session > handle references a session that is not loaded > > So it looks like the session is still context saved, pointing to an > error in the toolkit. > Yes, this jogged my memory that we talked about implementing this between Imran (The other main developer) and I. If we don't context save in the tool, both tpm2-abrmd and in-kernel will flush the handle. I think the cleanest option would be to add a --wait-for-sighup option where the tool sleeps until sighup is delivered. For scripts, folks could just lunch it in the background, grab the handle output and then kill -s sighuhp %1 or whatever. That's pretty easy to add, let me know and I can respond with a PR on github. <snip>
