* about context gap
@ 2017-09-16 15:36 ` Jarkko Sakkinen
0 siblings, 0 replies; 8+ messages in thread
From: Jarkko Sakkinen @ 2017-09-16 15:36 UTC (permalink / raw)
To: linux-security-module
Hi
While sitting at the airport I started to think a bit about the context
gap issue.
I think first thing that would make sense would be to have a 64-bit
shadow count for every TPM space i.e.
atomic_long_t tpm2_ctx_cnt;
struct tpm2_space {
/* ... */
u64 ctx_cnt;
};
For every create and load of a session you will read the global count
and increase it. This way we have get a well defined order.
With this organization we could for example put tpm spaces to a
red-black tree and refresh the oldest tpm space (just first thought
that came to mind).
PS. While doing LPC and LSS slides I found error from the TPM 2.0
commands specification. TPM2_ContextSave can never emit
TPM2_RC_CONTEXT_GAP albeit the specification says so.
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* about context gap
@ 2017-09-16 15:36 ` Jarkko Sakkinen
0 siblings, 0 replies; 8+ messages in thread
From: Jarkko Sakkinen @ 2017-09-16 15:36 UTC (permalink / raw)
To: James.Bottomley; +Cc: linux-integrity, linux-security-module
Hi
While sitting at the airport I started to think a bit about the context
gap issue.
I think first thing that would make sense would be to have a 64-bit
shadow count for every TPM space i.e.
atomic_long_t tpm2_ctx_cnt;
struct tpm2_space {
/* ... */
u64 ctx_cnt;
};
For every create and load of a session you will read the global count
and increase it. This way we have get a well defined order.
With this organization we could for example put tpm spaces to a
red-black tree and refresh the oldest tpm space (just first thought
that came to mind).
PS. While doing LPC and LSS slides I found error from the TPM 2.0
commands specification. TPM2_ContextSave can never emit
TPM2_RC_CONTEXT_GAP albeit the specification says so.
/Jarkko
^ permalink raw reply [flat|nested] 8+ messages in thread
* about context gap
2017-09-16 15:36 ` Jarkko Sakkinen
@ 2017-09-18 18:02 ` Jarkko Sakkinen
-1 siblings, 0 replies; 8+ messages in thread
From: Jarkko Sakkinen @ 2017-09-18 18:02 UTC (permalink / raw)
To: linux-security-module
On Sat, Sep 16, 2017 at 08:36:29AM -0700, Jarkko Sakkinen wrote:
> Hi
>
> While sitting at the airport I started to think a bit about the context
> gap issue.
>
> I think first thing that would make sense would be to have a 64-bit
> shadow count for every TPM space i.e.
>
> atomic_long_t tpm2_ctx_cnt;
>
> struct tpm2_space {
> /* ... */
> u64 ctx_cnt;
> };
>
> For every create and load of a session you will read the global count
> and increase it. This way we have get a well defined order.
>
> With this organization we could for example put tpm spaces to a
> red-black tree and refresh the oldest tpm space (just first thought
> that came to mind).
>
> PS. While doing LPC and LSS slides I found error from the TPM 2.0
> commands specification. TPM2_ContextSave can never emit
> TPM2_RC_CONTEXT_GAP albeit the specification says so.
>
> /Jarkko
Other than context gap it would probably make sense to estimate TPM
capacity in order to make implementation more intelligent. We could
measure memory capacity of a TPM in the driver initialization by filling
it with fixed size dummy objects.
TPM2_GetCapability gives stuff that cannot be really trusted as spec
compliant TPM HW could just return always '1' for max.
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: about context gap
@ 2017-09-18 18:02 ` Jarkko Sakkinen
0 siblings, 0 replies; 8+ messages in thread
From: Jarkko Sakkinen @ 2017-09-18 18:02 UTC (permalink / raw)
To: James.Bottomley; +Cc: linux-integrity, linux-security-module
On Sat, Sep 16, 2017 at 08:36:29AM -0700, Jarkko Sakkinen wrote:
> Hi
>
> While sitting at the airport I started to think a bit about the context
> gap issue.
>
> I think first thing that would make sense would be to have a 64-bit
> shadow count for every TPM space i.e.
>
> atomic_long_t tpm2_ctx_cnt;
>
> struct tpm2_space {
> /* ... */
> u64 ctx_cnt;
> };
>
> For every create and load of a session you will read the global count
> and increase it. This way we have get a well defined order.
>
> With this organization we could for example put tpm spaces to a
> red-black tree and refresh the oldest tpm space (just first thought
> that came to mind).
>
> PS. While doing LPC and LSS slides I found error from the TPM 2.0
> commands specification. TPM2_ContextSave can never emit
> TPM2_RC_CONTEXT_GAP albeit the specification says so.
>
> /Jarkko
Other than context gap it would probably make sense to estimate TPM
capacity in order to make implementation more intelligent. We could
measure memory capacity of a TPM in the driver initialization by filling
it with fixed size dummy objects.
TPM2_GetCapability gives stuff that cannot be really trusted as spec
compliant TPM HW could just return always '1' for max.
/Jarkko
^ permalink raw reply [flat|nested] 8+ messages in thread
* about context gap
2017-09-18 18:02 ` Jarkko Sakkinen
@ 2017-09-26 18:46 ` Ken Goldman
-1 siblings, 0 replies; 8+ messages in thread
From: Ken Goldman @ 2017-09-26 18:46 UTC (permalink / raw)
To: linux-security-module
On 9/18/2017 2:02 PM, Jarkko Sakkinen wrote:
> Other than context gap it would probably make sense to estimate TPM
> capacity in order to make implementation more intelligent. We could
> measure memory capacity of a TPM in the driver initialization by filling
> it with fixed size dummy objects.
>
> TPM2_GetCapability gives stuff that cannot be really trusted as spec
> compliant TPM HW could just return always '1' for max.
I don't see anything in the TPM specs that claim the TPM can return 1.
E.g., the PC Client spec says that loaded sessions must return a minimum
of 3. Active sessions must return a minimum of 64.
I think the resource manager can safely use these getcapability values.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: about context gap
@ 2017-09-26 18:46 ` Ken Goldman
0 siblings, 0 replies; 8+ messages in thread
From: Ken Goldman @ 2017-09-26 18:46 UTC (permalink / raw)
Cc: linux-integrity, linux-security-module
On 9/18/2017 2:02 PM, Jarkko Sakkinen wrote:
> Other than context gap it would probably make sense to estimate TPM
> capacity in order to make implementation more intelligent. We could
> measure memory capacity of a TPM in the driver initialization by filling
> it with fixed size dummy objects.
>
> TPM2_GetCapability gives stuff that cannot be really trusted as spec
> compliant TPM HW could just return always '1' for max.
I don't see anything in the TPM specs that claim the TPM can return 1.
E.g., the PC Client spec says that loaded sessions must return a minimum
of 3. Active sessions must return a minimum of 64.
I think the resource manager can safely use these getcapability values.
^ permalink raw reply [flat|nested] 8+ messages in thread
* about context gap
2017-09-16 15:36 ` Jarkko Sakkinen
@ 2017-09-26 19:10 ` Ken Goldman
-1 siblings, 0 replies; 8+ messages in thread
From: Ken Goldman @ 2017-09-26 19:10 UTC (permalink / raw)
To: linux-security-module
On 9/16/2017 11:36 AM, Jarkko Sakkinen wrote:
> Hi
>
> While sitting at the airport I started to think a bit about the context
> gap issue.
>
> I think first thing that would make sense would be to have a 64-bit
> shadow count for every TPM space i.e.
>
> atomic_long_t tpm2_ctx_cnt;
>
> struct tpm2_space {
> /* ... */
> u64 ctx_cnt;
> };
>
> For every create and load of a session you will read the global count
> and increase it. This way we have get a well defined order.
>
> With this organization we could for example put tpm spaces to a
> red-black tree and refresh the oldest tpm space (just first thought
> that came to mind).
I think the algorithm is as follows:
1 - Each saved context has a sequence number. It can either be
extracted once and saved in a table or extracted from the context blob
when needed.
2 - When a startauthsession or contextload returns the
TPM_RC_CONTEXT_GAP error
2A - find the lowest context blob sequence number
2B - contextload it
2C - contextsave it
This is just for sessions, not objects.
~~
A fundamental design question is whether the application can call
contextsave for sessions, or whether the command is reserved for the
resource manager.
I personally think it adds a lot of complication - the session blob has
to be sort of virtualized. The use case - one application saving a
session, then handing it over to another application that loads it -
doesn't seem worth the complexity.
It should be discussed up front, because it affects the code.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: about context gap
@ 2017-09-26 19:10 ` Ken Goldman
0 siblings, 0 replies; 8+ messages in thread
From: Ken Goldman @ 2017-09-26 19:10 UTC (permalink / raw)
Cc: linux-integrity, linux-security-module
On 9/16/2017 11:36 AM, Jarkko Sakkinen wrote:
> Hi
>
> While sitting at the airport I started to think a bit about the context
> gap issue.
>
> I think first thing that would make sense would be to have a 64-bit
> shadow count for every TPM space i.e.
>
> atomic_long_t tpm2_ctx_cnt;
>
> struct tpm2_space {
> /* ... */
> u64 ctx_cnt;
> };
>
> For every create and load of a session you will read the global count
> and increase it. This way we have get a well defined order.
>
> With this organization we could for example put tpm spaces to a
> red-black tree and refresh the oldest tpm space (just first thought
> that came to mind).
I think the algorithm is as follows:
1 - Each saved context has a sequence number. It can either be
extracted once and saved in a table or extracted from the context blob
when needed.
2 - When a startauthsession or contextload returns the
TPM_RC_CONTEXT_GAP error
2A - find the lowest context blob sequence number
2B - contextload it
2C - contextsave it
This is just for sessions, not objects.
~~
A fundamental design question is whether the application can call
contextsave for sessions, or whether the command is reserved for the
resource manager.
I personally think it adds a lot of complication - the session blob has
to be sort of virtualized. The use case - one application saving a
session, then handing it over to another application that loads it -
doesn't seem worth the complexity.
It should be discussed up front, because it affects the code.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-09-26 19:10 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-16 15:36 about context gap Jarkko Sakkinen
2017-09-16 15:36 ` Jarkko Sakkinen
2017-09-18 18:02 ` Jarkko Sakkinen
2017-09-18 18:02 ` Jarkko Sakkinen
2017-09-26 18:46 ` Ken Goldman
2017-09-26 18:46 ` Ken Goldman
2017-09-26 19:10 ` Ken Goldman
2017-09-26 19:10 ` Ken Goldman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.