Seal/Unseal trusted keys against PCR policy

Seal/Unseal trusted keys against PCR policy

[Sughosh Ganu]

hi,
I am looking to use PCR policy to seal and unseal trusted keys. I
tried using the interface described in the documentation [1], but I
get an unseal error at the time of a key load operation. I came across
a thread [2] which is pretty much the error that I get. As per my
understanding of what James had explained on that thread, the API was
broken for TPM2.0 based devices. Has that since been fixed. If so, has
there been a change in the user interface for sealing and unsealing
the trusted keys.

Here are the steps that I follow.

# tpm2_createpolicy --policy-pcr --pcr-list sha256:10 --policy
pcr10_bin.policy > pcr.policy

# cat pcr.policy
16ef916486174ed6f68b09629d2920dd7493d0918fff1247420934c3836100d3

#keyctl add trusted kmk-pcr "new 32 keyhandle=0x81000001 hash=sha256
policydigest=`cat pcr.policy`" @u
588568314

# keyctl pipe 588568314 > kmk-pcr.blob

On a reboot (or even w/o a reboot, after deleting the key)
#keyctl add trusted kmk-pcr "load `cat kmk-pcr.blob`
keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr.policy`" @u
add_key: Operation not permitted

My setup is a Qemu arm64 virt platform running Debian11, linux kernel
built with current master branch, and swtpm 2.0 implementation as the
TPM backend.

-sughosh

[1] - Documentation/security/keys/trusted-encrypted.rst
[2] - https://lore.kernel.org/linux-integrity/20191206212031.GE9971@linux.intel.com/T/

Re: Seal/Unseal trusted keys against PCR policy

[James Bottomley]

On Tue, 2022-12-27 at 09:44 +0530, Sughosh Ganu wrote:
> hi,
> I am looking to use PCR policy to seal and unseal trusted keys. I
> tried using the interface described in the documentation [1], but I
> get an unseal error at the time of a key load operation. I came
> across a thread [2] which is pretty much the error that I get. As per
> my understanding of what James had explained on that thread, the API
> was broken for TPM2.0 based devices. Has that since been fixed.

Yes, that's been fixed for a while:

f2219745250f security: keys: trusted: use ASN.1 TPM2 key format for the
blobs

>  If so, has there been a change in the user interface for sealing and
> unsealing the trusted keys.
> 
> Here are the steps that I follow.
> 
> # tpm2_createpolicy --policy-pcr --pcr-list sha256:10 --policy
> pcr10_bin.policy > pcr.policy
> 
> # cat pcr.policy
> 16ef916486174ed6f68b09629d2920dd7493d0918fff1247420934c3836100d3
> 
> #keyctl add trusted kmk-pcr "new 32 keyhandle=0x81000001 hash=sha256
> policydigest=`cat pcr.policy`" @u
> 588568314
> 
> # keyctl pipe 588568314 > kmk-pcr.blob
> 
> On a reboot (or even w/o a reboot, after deleting the key)
> #keyctl add trusted kmk-pcr "load `cat kmk-pcr.blob`
> keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr.policy`" @u
> add_key: Operation not permitted

To reload a sealed key, you have to construct a policy session with the
matching policy digest and pass it down to the kernel with
policyhandle=

James

Re: Seal/Unseal trusted keys against PCR policy

[Sughosh Ganu]

hi James,

On Tue, 27 Dec 2022 at 21:10, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2022-12-27 at 09:44 +0530, Sughosh Ganu wrote:
> > hi,
> > I am looking to use PCR policy to seal and unseal trusted keys. I
> > tried using the interface described in the documentation [1], but I
> > get an unseal error at the time of a key load operation. I came
> > across a thread [2] which is pretty much the error that I get. As per
> > my understanding of what James had explained on that thread, the API
> > was broken for TPM2.0 based devices. Has that since been fixed.
>
> Yes, that's been fixed for a while:
>
> f2219745250f security: keys: trusted: use ASN.1 TPM2 key format for the
> blobs
>
> >  If so, has there been a change in the user interface for sealing and
> > unsealing the trusted keys.
> >
> > Here are the steps that I follow.
> >
> > # tpm2_createpolicy --policy-pcr --pcr-list sha256:10 --policy
> > pcr10_bin.policy > pcr.policy
> >
> > # cat pcr.policy
> > 16ef916486174ed6f68b09629d2920dd7493d0918fff1247420934c3836100d3
> >
> > #keyctl add trusted kmk-pcr "new 32 keyhandle=0x81000001 hash=sha256
> > policydigest=`cat pcr.policy`" @u
> > 588568314
> >
> > # keyctl pipe 588568314 > kmk-pcr.blob
> >
> > On a reboot (or even w/o a reboot, after deleting the key)
> > #keyctl add trusted kmk-pcr "load `cat kmk-pcr.blob`
> > keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr.policy`" @u
> > add_key: Operation not permitted
>
> To reload a sealed key, you have to construct a policy session with the
> matching policy digest and pass it down to the kernel with
> policyhandle=

Thanks for your reply. For reloading the sealed key, I am trying to
start a policy session through the tpm2_startauthsession command,
followed by the tpm2_policypcr command to get the same policy digest.
However, I am not sure how to get the session handle. As per my
understanding, the policyhandle is a uint32_t object. However, none of
the above two commands give back the session handle. I tried the
tpm2_getcap command with the handles-saved-session, which shows a
handle once I have run the tpm2_startauthsession command. However,
providing this value to the keyctl command as policyhandle does not
work. Can you please point out what I am doing wrong?

-sughosh

Re: Seal/Unseal trusted keys against PCR policy

[James Bottomley]

On Thu, 2022-12-29 at 02:10 +0530, Sughosh Ganu wrote:
[...]
> Thanks for your reply. For reloading the sealed key, I am trying to
> start a policy session through the tpm2_startauthsession command,
> followed by the tpm2_policypcr command to get the same policy digest.
> However, I am not sure how to get the session handle. As per my
> understanding, the policyhandle is a uint32_t object. However, none
> of the above two commands give back the session handle. I tried the
> tpm2_getcap command with the handles-saved-session, which shows a
> handle once I have run the tpm2_startauthsession command. However,
> providing this value to the keyctl command as policyhandle does not
> work. Can you please point out what I am doing wrong?

I'm afraid I gave up on the Intel toolkit long ago because of the
constantly changing command options.  I can show you how to do it with
the IBM toolkit, though:

https://build.opensuse.org/package/show/security/ibmtss

The main thing you have to do is connect to the TPM not through the
resource manager so the policy session survives multiple commands

export TPM_DEVICE=/dev/tpm0

Then you can seal to say PCR7 which simply records the secure boot
state:

root@testdeb:~# cat /sys/class/tpm/tpm0/pcr-sha256/7
65CAF8DD1E0EA7A6347B635D2B379C93B9A1351EDC2AFC3ECDA700E534EB3068

So you can now construct the policy exactly and ask policymaker what
its hash is:

root@testdeb:~# tsspolicymakerpcr -pr -bm 000080 -if /sys/class/tpm/tpm0/pcr-sha256/7 > tmp.policy
root@testdeb:~# tsspolicymaker -if ~/tmp.policy -ns
policy digest:
4cc48043aedaae487452bb407e8fc21d25c3a412ffc9473cf2552ddc659e97c1

So now you know the policy hash, you can create a key

root@testdeb:~# keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=4cc48043aedaae487452bb407e8fc21d25c3a412ffc9473cf2552ddc659e97c1" @u
214245338
keyctl pipe %trusted:kmk > key.tpm
keyctl unlink %trusted:kmk
1 links removed

Now you can reload it if you construct the correct policy

root@testdeb:~# tssstartauthsession -se p
Handle 03000000
root@testdeb:~# tsspolicypcr -ha 03000000 -bm 000080

Now you can check this policy register matches the hash you have above:

root@testdeb:~# tsspolicygetdigest -ha 03000000
 policyDigest length 32
 4c c4 80 43 ae da ae 48 74 52 bb 40 7e 8f c2 1d 
 25 c3 a4 12 ff c9 47 3c f2 55 2d dc 65 9e 97 c1 

And you can now use this policy handle as the reload policy for the
key:

root@testdeb:~# keyctl add trusted kmk "load `cat ~/key.tpm` policyhandle=0x03000000" @u
872397032


James

Re: Seal/Unseal trusted keys against PCR policy

[Sughosh Ganu]

hi James,

On Thu, 29 Dec 2022 at 04:18, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Thu, 2022-12-29 at 02:10 +0530, Sughosh Ganu wrote:
> [...]
> > Thanks for your reply. For reloading the sealed key, I am trying to
> > start a policy session through the tpm2_startauthsession command,
> > followed by the tpm2_policypcr command to get the same policy digest.
> > However, I am not sure how to get the session handle. As per my
> > understanding, the policyhandle is a uint32_t object. However, none
> > of the above two commands give back the session handle. I tried the
> > tpm2_getcap command with the handles-saved-session, which shows a
> > handle once I have run the tpm2_startauthsession command. However,
> > providing this value to the keyctl command as policyhandle does not
> > work. Can you please point out what I am doing wrong?
>
> I'm afraid I gave up on the Intel toolkit long ago because of the
> constantly changing command options.  I can show you how to do it with
> the IBM toolkit, though:
>
> https://build.opensuse.org/package/show/security/ibmtss
>
> The main thing you have to do is connect to the TPM not through the
> resource manager so the policy session survives multiple commands
>
> export TPM_DEVICE=/dev/tpm0
>
> Then you can seal to say PCR7 which simply records the secure boot
> state:
>
> root@testdeb:~# cat /sys/class/tpm/tpm0/pcr-sha256/7
> 65CAF8DD1E0EA7A6347B635D2B379C93B9A1351EDC2AFC3ECDA700E534EB3068
>
> So you can now construct the policy exactly and ask policymaker what
> its hash is:
>
> root@testdeb:~# tsspolicymakerpcr -pr -bm 000080 -if /sys/class/tpm/tpm0/pcr-sha256/7 > tmp.policy
> root@testdeb:~# tsspolicymaker -if ~/tmp.policy -ns
> policy digest:
> 4cc48043aedaae487452bb407e8fc21d25c3a412ffc9473cf2552ddc659e97c1
>
> So now you know the policy hash, you can create a key
>
> root@testdeb:~# keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=4cc48043aedaae487452bb407e8fc21d25c3a412ffc9473cf2552ddc659e97c1" @u
> 214245338
> keyctl pipe %trusted:kmk > key.tpm
> keyctl unlink %trusted:kmk
> 1 links removed
>
> Now you can reload it if you construct the correct policy
>
> root@testdeb:~# tssstartauthsession -se p
> Handle 03000000
> root@testdeb:~# tsspolicypcr -ha 03000000 -bm 000080
>
> Now you can check this policy register matches the hash you have above:
>
> root@testdeb:~# tsspolicygetdigest -ha 03000000
>  policyDigest length 32
>  4c c4 80 43 ae da ae 48 74 52 bb 40 7e 8f c2 1d
>  25 c3 a4 12 ff c9 47 3c f2 55 2d dc 65 9e 97 c1
>
> And you can now use this policy handle as the reload policy for the
> key:
>
> root@testdeb:~# keyctl add trusted kmk "load `cat ~/key.tpm` policyhandle=0x03000000" @u
> 872397032

I am able to unseal and load the key using the tss tools that you
pointed to above. Thanks a lot for your help! So the issue seems to be
that the Intel tpm2_startauthsession tool does not return the policy
handle, which the unseal operation expects. Not sure if I did
something wrong in using the tool, but fwiw, these are the steps that
I followed.

# tpm2_startauthsession -S session.ctx --policy-session
# tpm2_policypcr -S session.ctx -l sha256:10

The tpm2_policypcr returns the same policy digest that was generated
at the time of policy creation. So that is not an issue. But
tpm2_startauthsession does not return any handle value, it just
creates the session.ctx file.

-sughosh

Re: Seal/Unseal trusted keys against PCR policy

[Ken Goldman]

On 12/28/2022 5:48 PM, James Bottomley wrote:
> The main thing you have to do is connect to the TPM not through the
> resource manager so the policy session survives multiple commands
>
> export TPM_DEVICE=/dev/tpm0

Just FYI, as James says, command line utilities interact with the 
resource manager.  When I want to run command line programs through the 
resource manager, I use a proxy to keep the /dev/tpmrm0 session connected.

https://github.com/kgoldman/ibmtss/blob/master/utils/tpmproxy.c holds an 
open source proxy.

Re: Seal/Unseal trusted keys against PCR policy

[William Roberts]

On Fri, Jan 6, 2023, 15:55 Ken Goldman <kgold@linux.ibm.com> wrote:
>
> On 12/28/2022 5:48 PM, James Bottomley wrote:
> > The main thing you have to do is connect to the TPM not through the
> > resource manager so the policy session survives multiple commands
> >
> > export TPM_DEVICE=/dev/tpm0
>
> Just FYI, as James says, command line utilities interact with the
> resource manager.  When I want to run command line programs through the
> resource manager, I use a proxy to keep the /dev/tpmrm0 session connected.
>
> https://github.com/kgoldman/ibmtss/blob/master/utils/tpmproxy.c holds an
> open source proxy.
>

If you need to do this in production that tpmproxy allows anyone to
connect to it. So while it's open it
would circumvent the permissions on /dev/tpmrm0. You can just use
tpm2-tools, which uses
contexts and avoids this problem.

Re: Seal/Unseal trusted keys against PCR policy

[James Bottomley]

On Fri, 2023-01-06 at 16:23 -0600, William Roberts wrote:
> On Fri, Jan 6, 2023, 15:55 Ken Goldman <kgold@linux.ibm.com> wrote:
> > 
> > On 12/28/2022 5:48 PM, James Bottomley wrote:
> > > The main thing you have to do is connect to the TPM not through
> > > the
> > > resource manager so the policy session survives multiple commands
> > > 
> > > export TPM_DEVICE=/dev/tpm0
> > 
> > Just FYI, as James says, command line utilities interact with the
> > resource manager.  When I want to run command line programs through
> > the
> > resource manager, I use a proxy to keep the /dev/tpmrm0 session
> > connected.
> > 
> > https://github.com/kgoldman/ibmtss/blob/master/utils/tpmproxy.c hol
> > ds an
> > open source proxy.
> > 
> 
> If you need to do this in production that tpmproxy allows anyone to
> connect to it. So while it's open it would circumvent the permissions
> on /dev/tpmrm0. You can just use tpm2-tools, which uses contexts and
> avoids this problem.

The specific issue with this is that using contexts, no-one could
figure out a way to pass the session into the kernel:

https://lore.kernel.org/linux-integrity/CADg8p94kTNkoByjLhEij3KkigLxhwU8PxnO82cRaO0Ejh7T3Zg@mail.gmail.com/

How should this be done?

James

Re: Seal/Unseal trusted keys against PCR policy

[Ken Goldman]

I discourage anyone from using scripted command line tools as production 
code.  IMHO, they're fine for learning and prototyping but that's all.

On 1/6/2023 5:23 PM, William Roberts wrote:
> If you need to do this in production that tpmproxy allows anyone to
> connect to it. So while it's open it
> would circumvent the permissions on /dev/tpmrm0. You can just use
> tpm2-tools, which uses
> contexts and avoids this problem.

Re: Seal/Unseal trusted keys against PCR policy

[William Roberts]

On Fri, Jan 6, 2023 at 5:17 PM Ken Goldman <kgold@linux.ibm.com> wrote:
>
> I discourage anyone from using scripted command line tools as production
> code.  IMHO, they're fine for learning and prototyping but that's all.

Well you can discourage it all you want but:
1. People do it
2. Shell languages exist for a reason
3. There is no semantic difference between a shell script and a program.

This is one of those pedantry vs pragmatism idioms.

>
> On 1/6/2023 5:23 PM, William Roberts wrote:
> > If you need to do this in production that tpmproxy allows anyone to
> > connect to it. So while it's open it
> > would circumvent the permissions on /dev/tpmrm0. You can just use
> > tpm2-tools, which uses
> > contexts and avoids this problem.

Re: Seal/Unseal trusted keys against PCR policy

[Sughosh Ganu]

hi Bill,

On Sat, 7 Jan 2023 at 04:43, William Roberts <bill.c.roberts@gmail.com> wrote:
>
>
>
> On Fri, Jan 6, 2023, 17:07 James Bottomley <James.Bottomley@hansenpartnership.com> wrote:
>>
>> On Fri, 2023-01-06 at 16:23 -0600, William Roberts wrote:
>> > On Fri, Jan 6, 2023, 15:55 Ken Goldman <kgold@linux.ibm.com> wrote:
>> > >
>> > > On 12/28/2022 5:48 PM, James Bottomley wrote:
>> > > > The main thing you have to do is connect to the TPM not through
>> > > > the
>> > > > resource manager so the policy session survives multiple commands
>> > > >
>> > > > export TPM_DEVICE=/dev/tpm0
>> > >
>> > > Just FYI, as James says, command line utilities interact with the
>> > > resource manager.  When I want to run command line programs through
>> > > the
>> > > resource manager, I use a proxy to keep the /dev/tpmrm0 session
>> > > connected.
>> > >
>> > > https://github.com/kgoldman/ibmtss/blob/master/utils/tpmproxy.c hol
>> > > ds an
>> > > open source proxy.
>> > >
>> >
>> > If you need to do this in production that tpmproxy allows anyone to
>> > connect to it. So while it's open it would circumvent the permissions
>> > on /dev/tpmrm0. You can just use tpm2-tools, which uses contexts and
>> > avoids this problem.
>>
>> The specific issue with this is that using contexts, no-one could
>> figure out a way to pass the session into the kernel:
>>
>> https://lore.kernel.org/linux-integrity/CADg8p94kTNkoByjLhEij3KkigLxhwU8PxnO82cRaO0Ejh7T3Zg@mail.gmail.com/
>>
>> How should this be done?
>
>
> 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
[  217.222214] trusted_key: key_unseal failed (-1)
add_key: Operation not permitted

After running these commands, I get the above error. I am able to get
the key unsealing work with the tss commands from IBM that James had
highlighted earlier.

-sughosh

>
> https://github.com/tpm2-software/tpm2-tools/blob/8cbc4bbaebc4fa135e35dabd6d9ab36ac05eb72b/tools/tpm2_sessionconfig.c#L66
>
> Apologies for any HTML, I have no idea what Gmail on Android does, I have no plaintext option. Yes there are other mail clients, and yes I think they all suck :-p
>>
>>
>> James
>>
>>

Re: Seal/Unseal trusted keys against PCR policy

[James Bottomley]

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@gmail.com> 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.


> [  217.222214] trusted_key: key_unseal failed (-1)
> add_key: Operation not permitted
> 
> After running these commands, I get the above error. I am able to get
> the key unsealing work with the tss commands from IBM that James had
> highlighted earlier.
> 
> -sughosh
> 
> > 
> > https://github.com/tpm2-software/tpm2-tools/blob/8cbc4bbaebc4fa135e35dabd6d9ab36ac05eb72b/tools/tpm2_sessionconfig.c#L66
> > 
> > Apologies for any HTML, I have no idea what Gmail on Android does,
> > I have no plaintext option. Yes there are other mail clients, and
> > yes I think they all suck :-p
> > 

The kernel lists discard email with html parts, which is why none of
the rest of us saw this except that there was a reply.

James

Re: Seal/Unseal trusted keys against PCR policy

[William Roberts]

On Wed, Jan 11, 2023 at 6:31 AM James Bottomley
<James.Bottomley@hansenpartnership.com> 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@gmail.com> 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>

Re: Seal/Unseal trusted keys against PCR policy

[James Bottomley]

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@hansenpartnership.com> 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@HansenPartnership.com/

James