On Wed, 2023-01-11 at 07:50 -0600, William Roberts wrote: > 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: [...] > > > > > [ 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. I don't think that would work: The in-kernel resource manager will context save the session while the userspace program isn't using the TPM (so that's while a TPM device read/write is active), so even if you hold the process running or even the /dev/tpmrm0 fd open, the session won't be in a state to pass into the kernel. What you really have to do to get this to work is to bypass the resource manager because you're trying to share a session between two otherwise separately managed uses of the TPM. Using a session constructed elsewhere is a security problem anyway because you can't share nonces, so the policy patches that stalled a year or so ago fixed this by allowing the kernel itself to construct the policy session, so you didn't have to pass in the handle: https://lore.kernel.org/linux-integrity/20210521004401.4167-1-James.Bottomley@xxxxxxxxxxxxxxxxxxxxx/ James
