lkml.org 
[lkml]   [2017]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion
    On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:

    Good morning to everyone.

    > On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
    > > Just as an aside, has anyone given any thought about TPM2 resource
    > > management in things like TXT/tboot environments? The current tboot
    > > code makes a rather naive assumption that it can take a handle slot to
    > > protect its platform verification secret. Doing resource management
    > > correctly will require addressing extra-OS environments such as this
    > > which may have TPM2 state requirement issues.

    > The current implementation handles stuff created from regular
    > /dev/tpm0 so I do not think this would be an issue. You can only
    > access objects from a TPM space that are created within that space.

    Unless I misunderstand the number of transient objects which can be
    managed is a characteristic of the hardware and is a limited resource,
    hence our discussion on the notion of a resource manager to shuttle
    context in and out of these limited slots.

    On a Kabylake system, running the following command:

    getcapability -cap 6 | grep trans

    After booting into a TXT mediated measured launch environment (MLE) yields
    the following:

    TPM_PT 0000010e value 00000003 TPM_PT_HR_TRANSIENT_MIN - the minimum number of transient objects that can be held in TPM RAM

    TPM_PT 00000207 value 00000002 TPM_PT_HR_TRANSIENT_AVAIL - estimate of the number of additional transient objects that could be loaded into TPM RAM

    Booting without TXT results in the getcapability call indicating that
    three slots are available. Based on that and reading the tboot code,
    we are assuming the occupied slot is the ephemeral primary key
    generated by tboot which seals the verification secret.

    In an MLE it is possible to create and then flush a new ephemeral
    primary key which results in the following getcapability output:

    TPM_PT 00000207 value 00000003 TPM_PT_HR_TRANSIENT_AVAIL - estimate of
    the number of additional transient objects that could be loaded into TPM RAM

    Which is probably going to be pretty surprising to tboot in the event
    that it tries to re-verify the system state after a suspend event.

    So based on that it would seem there would need to be some semblance
    of cooperation between the resource manager and an extra-OS
    utilization of TPM2 resources such as tboot.

    Thoughts?

    > /Jarkko

    Greg

    As always,
    Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
    4206 N. 19th Ave. Specializing in information infra-structure
    Fargo, ND 58102 development.
    PH: 701-281-1686
    FAX: 701-281-3949 EMAIL: greg@enjellic.com
    ------------------------------------------------------------------------------
    "For a successful technology, reality must take precedence over public
    relations, for nature cannot be fooled."
    -- Richard Feynmann

    \
     
     \ /
      Last update: 2017-02-17 10:57    [W:6.786 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site