6:01 p.m.
There are two main parts to the direction I see the tools policy/session support heading:
1. The first is cleaning up all the code around session support and policy building. I
think now that I understand the topic better, I can organize this code a little better.
This is rather trivial and beside the main point.
2. Since abrmd 1.3 we have support for sessions across RM IPC connections and direct tpm
communications (/dev/tmp0) also has the same support. We have tools like tpm2_createpolicy
that are made up of multiple
commands to work around session flushing on IPC RM disconnections. tpm2_createpolicy is
really comprised of 3 commands: tpm2_startauthsession, tpm2_policypcr and
tpm2_flushcontext.
I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users, but add
tpm2_startauthsession and tpm2_policypcr for the abrmd and direct tpm usages. Abrmd works
by using Tss2_Sys_ContextSave as the
marker of NOT flushing a session handle. Granted you also need the sessionAttributes set
to continue so the TPM doesn't kill it.
I think the flow for using the new tools would be something like this:
1. tpm2_createpolicy - create a pcr policy and spit out the policy digest
2. tpm2_create - create an object and set its policy digest as obtained in step 1
3. tpm2_startauthsession - create a pcr policy and spit out the session handle
4. tpm2_policypcr - satisfy policy via policy digest and pcr list obtained/used in step 1
as well as taking the session handle from step 3
5. tpm2_<tool> - use some tool passing the session handle from step 3
6. tpm2_flushcontext - flushes the handle from step 3
With that said, since tpm2_createpolicy is really a combination of the
tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and tpm2_flushcontext, all that could
be moved into lib, so each new tool and
create policy are really just calling into the same code.
Thoughts, am I missing something here?
This is a lot of work, so I would like to start it now, as it would be the major feature
set going towards 4.0 release.
Bill
8:18 a.m.
Hello Bill,
This (attached diagram) is what my thought process was, when designing the createpolicy
tool.
I concur the startauthsession and flushcontext can be separate tools that are currently
clubbed in the createpolicy tool.
[cid:CC18E3F2-C642-4662-9CEC-C1091AA18831@amr.corp.intel.com]
Thanks and Regards,
Imran Desai | imran.desai@intel.com<mailto:imran.desai@intel.com>
On Dec 19, 2017, at 11:01 AM, Roberts, William C
<william.c.roberts@intel.com<mailto:william.c.roberts@intel.com>> wrote:
There are two main parts to the direction I see the tools policy/session support heading:
1. The first is cleaning up all the code around session support and policy building. I
think now that I understand the topic better, I can organize this code a little better.
This is rather trivial and beside the main point.
2. Since abrmd 1.3 we have support for sessions across RM IPC connections and direct tpm
communications (/dev/tmp0) also has the same support. We have tools like tpm2_createpolicy
that are made up of multiple
commands to work around session flushing on IPC RM disconnections. tpm2_createpolicy is
really comprised of 3 commands: tpm2_startauthsession, tpm2_policypcr and
tpm2_flushcontext.
I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users, but add
tpm2_startauthsession and tpm2_policypcr for the abrmd and direct tpm usages. Abrmd works
by using Tss2_Sys_ContextSave as the
marker of NOT flushing a session handle. Granted you also need the sessionAttributes set
to continue so the TPM doesn't kill it.
I think the flow for using the new tools would be something like this:
1. tpm2_createpolicy - create a pcr policy and spit out the policy digest
2. tpm2_create - create an object and set its policy digest as obtained in step 1
3. tpm2_startauthsession - create a pcr policy and spit out the session handle
4. tpm2_policypcr - satisfy policy via policy digest and pcr list obtained/used in step 1
as well as taking the session handle from step 3
5. tpm2_<tool> - use some tool passing the session handle from step 3
6. tpm2_flushcontext - flushes the handle from step 3
With that said, since tpm2_createpolicy is really a combination of the
tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and tpm2_flushcontext, all that could
be moved into lib, so each new tool and
create policy are really just calling into the same code.
Thoughts, am I missing something here?
This is a lot of work, so I would like to start it now, as it would be the major feature
set going towards 4.0 release.
Bill
2:35 p.m.
Forgive me if this is obvious to you :-) but I'd like to understand and
clarify the above a bit more. In the procedure you've presented above does
step #4 change the state of the session to one that can be used?
Is then the procedure then something like:
1. tpm2_createpolicy - create a pcr policy and spit out the policy digest
eg: I create a policy based upon the current state of (eg) sha1:0,1,2,3 and
save this as 0123.policy
2. tpm2_create - create an object containing the policy created in #1 (+
keys?)
eg: I create an object which is sealed (???) against 0123.policy
Question: is there a need to perform a tpm2_load here or is it sufficient
that this exists temporarily?
3. tpm2_startauthsession - create a session handle for a given pcr policy
eg: I generate a session handle for a given policy, eg: 0123.policy and
return this as, say session.bin
4. tpm2_policypcr, given #1 and #3, check if either a supplied set of PCR
values or the current state of the PCR registers are specified in #1 match,
if so then the session handle is marked as being valid until step #6
5. tpm2_* with -S taking the output of #3 as input as required
Question: what happens if I issue a tpm2_* command without -S during this
time?
6. tpm2_flushcontext taking the session handle and/or object from #2 as
input. Any further attempts to use the session handle with tpm2_* -S
fails.
So an example session might proceed
$tpm2_createpolicy -P -f 0123.policy -g sha256 -L sha1:0,1,2
$ls
0123.policy
$tpm2_create -H 0x81010001 -g sha256 -G rsa -L 0123.policy
0x810100ff <- output handle, also assume 0x81010001 exists in the
above
$tpm2_startauthsession -L 0123.policy -s session.bin
$ls
session.bin
Now this is pure guesswork here
$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
FAIL
$tpm2_policypcr -k 0x81010001 -s session.bin -L
0123.policy <- reads sha1:0,1,2,3 from the TPM
OK
$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
$cat plain.txt
"This is a secret message"
$tpm2_flushcontext -H 0x810100ff <- our object from above
$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
FAIL
t.
Ian
On 19 December 2017 at 20:01, Roberts, William C <
william.c.roberts(a)intel.com> wrote:
There are two main parts to the direction I see the tools
policy/session
support heading:
1. The first is cleaning up all the code around session support and policy
building. I think now that I understand the topic better, I can organize
this code a little better. This is rather trivial and beside the main point.
2. Since abrmd 1.3 we have support for sessions across RM IPC connections
and direct tpm communications (/dev/tmp0) also has the same support. We
have tools like tpm2_createpolicy that are made up of multiple
commands to work around session flushing on IPC RM disconnections.
tpm2_createpolicy is really comprised of 3 commands: tpm2_startauthsession,
tpm2_policypcr and tpm2_flushcontext.
I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users, but add
tpm2_startauthsession and tpm2_policypcr for the abrmd and direct tpm
usages. Abrmd works by using Tss2_Sys_ContextSave as the
marker of NOT flushing a session handle. Granted you also need the
sessionAttributes set to continue so the TPM doesn't kill it.
I think the flow for using the new tools would be something like this:
1. tpm2_createpolicy - create a pcr policy and spit out the policy digest
2. tpm2_create - create an object and set its policy digest as obtained in
step 1
3. tpm2_startauthsession - create a pcr policy and spit out the session
handle
4. tpm2_policypcr - satisfy policy via policy digest and pcr list
obtained/used in step 1 as well as taking the session handle from step 3
5. tpm2_<tool> - use some tool passing the session handle from step 3
6. tpm2_flushcontext - flushes the handle from step 3
With that said, since tpm2_createpolicy is really a combination of the
tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and tpm2_flushcontext,
all that could be moved into lib, so each new tool and
create policy are really just calling into the same code.
Thoughts, am I missing something here?
This is a lot of work, so I would like to start it now, as it would be the
major feature set going towards 4.0 release.
Bill
_______________________________________________
tpm2 mailing list
tpm2(a)lists.01.org
https://lists.01.org/mailman/listinfo/tpm2
--
*Dr. Ian Oliver*
===============================
Privacy Engineering: via Amazon <http://www.amazon.co.uk/dp/1497569710>
*Twitter: @i_j_oliver*
3:47 p.m.
Hello Ian,
On 12/20/2017 03:35 PM, Ian Oliver wrote:
Forgive me if this is obvious to you :-) but I'd like to
understand and
clarify the above a bit more. In the procedure you've presented above does
step #4 change the state of the session to one that can be used?
Is then the procedure then something like:
1. tpm2_createpolicy - create a pcr policy and spit out the policy digest
eg: I create a policy based upon the current state of (eg) sha1:0,1,2,3 and
save this as 0123.policy
2. tpm2_create - create an object containing the policy created in #1 (+
keys?)
eg: I create an object which is sealed (???) against 0123.policy
Question: is there a need to perform a tpm2_load here or is it sufficient
that this exists temporarily?
You always need to do a TPM2_Load if you want to use an object created by the
TPM. The TPM2_Create commands just returns the public and private parts of an
object but doesn't keep anything in the TPM memory after is completed.
3. tpm2_startauthsession - create a session handle for a given pcr
policy
eg: I generate a session handle for a given policy, eg: 0123.policy and
return this as, say session.bin
No, here Bill weren't precise in the wording AFAICT. He said "creates a session
handle for a given pcr policy" but he should had said "creates a session handle
for a given session policy".
In other words, you are just creating an authentication session but still didn't
do any authentication based on the PCR state.
4. tpm2_policypcr, given #1 and #3, check if either a supplied set of
PCR
values or the current state of the PCR registers are specified in #1 match,
if so then the session handle is marked as being valid until step #6
Yes, this tool will send a TPM2_PolicyPCR() command to the TPM with the PCR
digest and so the session is changed from policySession to policyDigest.
About the session handle being valid until #6, this really depends if the
command sets TPM_ST_SESSIONS in the header tag field or TPM_ST_NO_SESSIONS?
If the latter, the provided session is flushed after the command completes
unless the policySession continueSession attribute is SET.
5. tpm2_* with -S taking the output of #3 as input as required
Question: what happens if I issue a tpm2_* command without -S during this
time?
If you are not provided a session that could satisfy the authentication
policy for your object, then the TPM will refuse the command to succeed
returning a TPM2_RC_BAD_AUTH response code as an error.
6. tpm2_flushcontext taking the session handle and/or object from
#2 as
input. Any further attempts to use the session handle with tpm2_* -S
fails.
Yes. After the session handle has been flushed from the TPM, any attempts
to authenticate using it will fail (in fact the session context won't even
load AFAICT).
So an example session might proceed
$tpm2_createpolicy -P -f 0123.policy -g sha256 -L sha1:0,1,2
$ls
0123.policy
$tpm2_create -H 0x81010001 -g sha256 -G rsa -L 0123.policy
0x810100ff <- output handle, also assume 0x81010001 exists in the
above
$tpm2_startauthsession -L 0123.policy -s session.bin
$ls
session.bin
Now this is pure guesswork here
$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
FAIL
$tpm2_policypcr -k 0x81010001 -s session.bin -L
0123.policy <- reads sha1:0,1,2,3 from the TPM
OK
$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
$cat plain.txt
"This is a secret message"
$tpm2_flushcontext -H 0x810100ff <- our object from above
$tpm2_decrypt -k 0x81010001 -I secret.enc -o plain.txt -S session.bin
FAIL
Yes, this is mostly correct. Please read my previous emails regardless
some of the details, but in general it will work as you said.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
3:14 p.m.
Hello Bill,
On 12/19/2017 07:01 PM, Roberts, William C wrote:
There are two main parts to the direction I see the tools
policy/session support heading:
1. The first is cleaning up all the code around session support and policy building. I
think now that I understand the topic better, I can organize this code a little better.
This is rather trivial and beside the main point.
Agreed, I've seen your PR in the repo and I think it's good.
2. Since abrmd 1.3 we have support for sessions across RM IPC connections and direct tpm
communications (/dev/tmp0) also has the same support. We have tools like tpm2_createpolicy
that are made up of multiple
commands to work around session flushing on IPC RM disconnections. tpm2_createpolicy is
really comprised of 3 commands: tpm2_startauthsession, tpm2_policypcr and
tpm2_flushcontext.
Absolutely agree. And as a matter of fact that's exactly what's done by the IBM
TSS, it has separate tools called startauthsession, policypcr and flushcontext.
I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users,
but add tpm2_startauthsession and tpm2_policypcr for the abrmd and direct tpm usages.
Abrmd works by using Tss2_Sys_ContextSave as the
Agreed too.
marker of NOT flushing a session handle. Granted you also need the
sessionAttributes set to continue so the TPM doesn't kill it.
Yes, in fact I don't know how chaining different commands with the current -S
option that takes a session handle is working nowadays since the tools aren't
setting the continueSession attribute. I guess the answer is that it doesn't?
I think the flow for using the new tools would be something like
this:
NOTE: I haven't looked at the final tpm2-abrmd implementation, I'm assuming that
it was implemented as previously discussed in the GitHub issues so please
let me know if I got some assumption wrong in the following:
1. tpm2_createpolicy - create a pcr policy and spit out the policy
digest
2. tpm2_create - create an object and set its policy digest as obtained in step 1
3. tpm2_startauthsession - create a pcr policy and spit out the session handle
To be precise, this tool won't sit out a session handle but a session context
(what's returned by a TPM2_ContextSave() command), right? Otherwise the session
will be flushed by the tpm2-abrmd since a call to Tss2_Sys_ContextSave() won't
be made.
4. tpm2_policypcr - satisfy policy via policy digest and pcr list
obtained/used in step 1 as well as taking the session handle from step 3
5. tpm2_<tool> - use some tool passing the session handle from step 3
This will work for a single tool, but my understanding is that sessions that
are saved with TPM2_ContextSave() can only be loaded once to prevent replay
attacks.
So the tpm2_<tool> should both get a session context and load it using the
TPM2_ContextLoad() command and export it again using a TPM2_ContextSave().
The next command can't use the same saved session context that the previous
command since the TPM will prevent it to be loaded. Even if the TPM would
allow, the session handle would already be flushed since TPM2_ContextLoad()
wouldn't be called before closing the SAPI connection.
6. tpm2_flushcontext - flushes the handle from step 3
With that said, since tpm2_createpolicy is really a combination of the
tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and tpm2_flushcontext, all that could
be moved into lib, so each new tool and
create policy are really just calling into the same code.
Agreed, I factored out a little bit so at least the tools that are doing
the session auth on each execute wouldn't duplicate the code. But we will
need to better split things since some functions logic are too monolithic.
Thoughts, am I missing something here?
I think your plan is the correct one. One question is if we will replace the
-S option that takes a session handle and instead take a session context or
if we will want to support the 3 options:
1) Chain tools passing session handles as long as are executed in an environment
that doesn't close the SAPI context (and so flushes the session).
2) Allow individual tools to manage their own session and auth like is the case
for tpm2_unseal and tpm2_nv{read,write}
3) Chain tools by passing saved session contexts.
In theory we currently support 1 and 2 (although as mentioned I don't know how
2 works if the tools don't set continueSession). So my question is if we want
to also include 3 or replace 2 by 3.
This is a lot of work, so I would like to start it now, as it would
be the major feature set going towards 4.0 release.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
5:40 p.m.
-----Original Message-----
From: Javier Martinez Canillas [mailto:javierm@redhat.com]
Sent: Friday, December 22, 2017 7:15 AM
To: Roberts, William C <william.c.roberts(a)intel.com>; tpm2(a)lists.01.org
Subject: Re: [tpm2] [RFC] Session Handling/Policy Support in Tools
Hello Bill,
On 12/19/2017 07:01 PM, Roberts, William C wrote:
> There are two main parts to the direction I see the tools policy/session support
heading:
>
> 1. The first is cleaning up all the code around session support and policy
building. I think now that I understand the topic better, I can organize this code a
little better. This is rather trivial and beside the main point.
Agreed, I've seen your PR in the repo and I think it's good.
>
> 2. Since abrmd 1.3 we have support for sessions across RM IPC
> connections and direct tpm communications (/dev/tmp0) also has the same
support. We have tools like tpm2_createpolicy that are made up of multiple
commands to work around session flushing on IPC RM disconnections.
tpm2_createpolicy is really comprised of 3 commands: tpm2_startauthsession,
tpm2_policypcr and tpm2_flushcontext.
>
Absolutely agree. And as a matter of fact that's exactly what's done by the IBM
TSS, it has separate tools called startauthsession, policypcr and flushcontext.
> I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users, but
> add tpm2_startauthsession and tpm2_policypcr for the abrmd and direct
> tpm usages. Abrmd works by using Tss2_Sys_ContextSave as the
Agreed too.
> marker of NOT flushing a session handle. Granted you also need the
sessionAttributes set to continue so the TPM doesn't kill it.
>
Yes, in fact I don't know how chaining different commands with the current -S
option that takes a session handle is working nowadays since the tools aren't
setting the continueSession attribute. I guess the answer is that it doesn't?
> I think the flow for using the new tools would be something like this:
>
NOTE: I haven't looked at the final tpm2-abrmd implementation, I'm assuming
that
it was implemented as previously discussed in the GitHub issues so please
let me know if I got some assumption wrong in the following:
> 1. tpm2_createpolicy - create a pcr policy and spit out the policy
> digest 2. tpm2_create - create an object and set its policy digest as
> obtained in step 1 3. tpm2_startauthsession - create a pcr policy and
> spit out the session handle
To be precise, this tool won't sit out a session handle but a session context
(what's returned by a TPM2_ContextSave() command), right? Otherwise the
session will be flushed by the tpm2-abrmd since a call to Tss2_Sys_ContextSave()
won't be made.
Correct. It needs to call ContextSave() for abrmd to mark it as not to be flushed.
It also need the continue bits set on the session IIUC.
> 4. tpm2_policypcr - satisfy policy via policy digest and pcr list
> obtained/used in step 1 as well as taking the session handle from step
> 3 5. tpm2_<tool> - use some tool passing the session handle from step
> 3
This will work for a single tool, but my understanding is that sessions that are
saved with TPM2_ContextSave() can only be loaded once to prevent replay
attacks.
So the tpm2_<tool> should both get a session context and load it using the
TPM2_ContextLoad() command and export it again using a TPM2_ContextSave().
The next command can't use the same saved session context that the previous
command since the TPM will prevent it to be loaded. Even if the TPM would
allow, the session handle would already be flushed since TPM2_ContextLoad()
wouldn't be called before closing the SAPI connection.
> 6. tpm2_flushcontext - flushes the handle from step 3
>
> With that said, since tpm2_createpolicy is really a combination of the
> tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and tpm2_flushcontext,
all that could be moved into lib, so each new tool and create policy are really just
calling into the same code.
>
Agreed, I factored out a little bit so at least the tools that are doing the session
auth on each execute wouldn't duplicate the code. But we will need to better
split things since some functions logic are too monolithic.
> Thoughts, am I missing something here?
>
I think your plan is the correct one. One question is if we will replace the -S option
that takes a session handle and instead take a session context or if we will want
to support the 3 options:
I don't think I made that clear, but I plan on -S to support:
1. a hex handle
2. a file path.
In the case of a file path, it would call context load/save every-call, so essentially
-S is both an input and output parameter via a file and that would get us around the 1
load per handle IIUC. Whenever -S is specified, the continueSession bit will get set
so the TPM itself doesn't flush it.
1) Chain tools passing session handles as long as are executed in an environment
that doesn't close the SAPI context (and so flushes the session).
2) Allow individual tools to manage their own session and auth like is the case
for tpm2_unseal and tpm2_nv{read,write}
3) Chain tools by passing saved session contexts.
In theory we currently support 1 and 2 (although as mentioned I don't know how
2 works if the tools don't set continueSession). So my question is if we want to
also include 3 or replace 2 by 3.
> This is a lot of work, so I would like to start it now, as it would be the major
feature set going towards 4.0 release.
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement Red Hat
4:49 p.m.
-----Original Message-----
From: Roberts, William C
Sent: Tuesday, December 26, 2017 9:40 AM
To: Javier Martinez Canillas <javierm(a)redhat.com>; tpm2(a)lists.01.org
Subject: RE: [tpm2] [RFC] Session Handling/Policy Support in Tools
> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javierm@redhat.com]
> Sent: Friday, December 22, 2017 7:15 AM
> To: Roberts, William C <william.c.roberts(a)intel.com>;
> tpm2(a)lists.01.org
> Subject: Re: [tpm2] [RFC] Session Handling/Policy Support in Tools
>
> Hello Bill,
>
> On 12/19/2017 07:01 PM, Roberts, William C wrote:
> > There are two main parts to the direction I see the tools
> > policy/session support
> heading:
> >
> > 1. The first is cleaning up all the code around session support and
> > policy
> building. I think now that I understand the topic better, I can
> organize this code a little better. This is rather trivial and beside the main
point.
>
> Agreed, I've seen your PR in the repo and I think it's good.
>
> >
> > 2. Since abrmd 1.3 we have support for sessions across RM IPC
> > connections and direct tpm communications (/dev/tmp0) also has the
> > same
> support. We have tools like tpm2_createpolicy that are made up of
> multiple commands to work around session flushing on IPC RM disconnections.
> tpm2_createpolicy is really comprised of 3 commands:
> tpm2_startauthsession, tpm2_policypcr and tpm2_flushcontext.
> >
>
> Absolutely agree. And as a matter of fact that's exactly what's done
> by the IBM TSS, it has separate tools called startauthsession, policypcr and
flushcontext.
>
> > I'm proposing we leave tpm2_createpolicy, for in-kernel-rm users,
> > but add tpm2_startauthsession and tpm2_policypcr for the abrmd and
> > direct tpm usages. Abrmd works by using Tss2_Sys_ContextSave as the
>
> Agreed too.
>
> > marker of NOT flushing a session handle. Granted you also need the
> sessionAttributes set to continue so the TPM doesn't kill it.
> >
>
> Yes, in fact I don't know how chaining different commands with the
> current -S option that takes a session handle is working nowadays
> since the tools aren't setting the continueSession attribute. I guess the
answer
is that it doesn't?
>
> > I think the flow for using the new tools would be something like this:
> >
>
> NOTE: I haven't looked at the final tpm2-abrmd implementation, I'm
> assuming that
> it was implemented as previously discussed in the GitHub issues so please
> let me know if I got some assumption wrong in the following:
>
> > 1. tpm2_createpolicy - create a pcr policy and spit out the policy
> > digest 2. tpm2_create - create an object and set its policy digest
> > as obtained in step 1 3. tpm2_startauthsession - create a pcr policy
> > and spit out the session handle
>
> To be precise, this tool won't sit out a session handle but a session
> context (what's returned by a TPM2_ContextSave() command), right?
> Otherwise the session will be flushed by the tpm2-abrmd since a call
> to Tss2_Sys_ContextSave() won't be made.
Correct. It needs to call ContextSave() for abrmd to mark it as not to be flushed.
It also need the continue bits set on the session IIUC.
>
> > 4. tpm2_policypcr - satisfy policy via policy digest and pcr list
> > obtained/used in step 1 as well as taking the session handle from
> > step
> > 3 5. tpm2_<tool> - use some tool passing the session handle from
> > step
> > 3
>
> This will work for a single tool, but my understanding is that
> sessions that are saved with TPM2_ContextSave() can only be loaded
> once to prevent replay attacks.
>
> So the tpm2_<tool> should both get a session context and load it using
> the
> TPM2_ContextLoad() command and export it again using a
TPM2_ContextSave().
>
> The next command can't use the same saved session context that the
> previous command since the TPM will prevent it to be loaded. Even if
> the TPM would allow, the session handle would already be flushed since
> TPM2_ContextLoad() wouldn't be called before closing the SAPI connection.
Hmm I missed some of this yesterday in my reply. I guess a lot of this depends
on what the RM is doing, if ContextSave() on the session handle
actually hits the TPM with abrmd, and if abrmd requires a ContextSave() on every
client that uses the session handle to keep it alive. Maybe something like
# calls context save but just deletes the file...
$ tpm2_startauthsession
handle: 0x1234
# abrmd keeps this handle alive until flush
tpm2_policypcr -S 0x1234
$ tpm2_tool1 -S 0x1234
$ tpm2_tool2 -S 0x1234
$ tpm2_flush 0x12334
This really depends on abrmd, but I'd like whatever works with abrmd to work
against a raw device directly as well.
This seems to be getting wonky.
>
> > 6. tpm2_flushcontext - flushes the handle from step 3
> >
> > With that said, since tpm2_createpolicy is really a combination of
> > the tpm2_startauthsession, tpm2_pcrlist, tpm2_policypcr and
> > tpm2_flushcontext,
> all that could be moved into lib, so each new tool and create policy
> are really just calling into the same code.
> >
>
> Agreed, I factored out a little bit so at least the tools that are
> doing the session auth on each execute wouldn't duplicate the code.
> But we will need to better split things since some functions logic are too
monolithic.
>
> > Thoughts, am I missing something here?
> >
>
> I think your plan is the correct one. One question is if we will
> replace the -S option that takes a session handle and instead take a
> session context or if we will want to support the 3 options:
I don't think I made that clear, but I plan on -S to support:
1. a hex handle
2. a file path.
In the case of a file path, it would call context load/save every-call, so essentially
-
S is both an input and output parameter via a file and that would get us around
the 1 load per handle IIUC. Whenever -S is specified, the continueSession bit will
get set so the TPM itself doesn't flush it.
>
> 1) Chain tools passing session handles as long as are executed in an
environment
> that doesn't close the SAPI context (and so flushes the session).
> 2) Allow individual tools to manage their own session and auth like is the case
> for tpm2_unseal and tpm2_nv{read,write}
> 3) Chain tools by passing saved session contexts.
>
> In theory we currently support 1 and 2 (although as mentioned I don't
> know how
> 2 works if the tools don't set continueSession). So my question is if
> we want to also include 3 or replace 2 by 3.
>
> > This is a lot of work, so I would like to start it now, as it would
> > be the major
> feature set going towards 4.0 release.
> >
>
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement Red Hat
1644
days inactive
1652
days old
6 comments
4 participants
participants (4)
-
Desai, Imran -
Ian Oliver -
Javier Martinez Canillas -
Roberts, William C