lkml.org 
[lkml]   [2023]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub
    From
    On 5/12/23 12:17, Ross Philipson wrote:
    > On 5/12/23 07:26, Matthew Garrett wrote:
    >> On Thu, May 04, 2023 at 02:50:16PM +0000, Ross Philipson wrote:
    >>
    >>> +static void sl_find_event_log(struct slr_table *slrt)
    >>
    >> If this is called after the EFI stub then we're presumably
    >> post-ExitBootServices and we're copied the TPM event log into a
    >> configuration table so it's available to the runtime kernel. That also
    >> means that we should be adding all further measurements to the Final
    >> Events Table rather than the initial event log. How's that handled here,
    >> both in terms of ensuring further events (generated by firmware or by
    >> us) get added to the right place, and in terms of ensuring the event
    >> logs the kernel has later on were covered appropriately? Or is the SL
    >> event log an entirely different thing that can be merged in later
    >> because it only covers the DRTM PCRs?
    >
    > This is a good point. At this point it is really something we
    > overlooked. We will have to revisit this and figure out the best way to
    > find the final event log depending on how things booted.

    I believe Ross misunderstood what you were asking for here. There are
    two reasons this is not possible or desired. The first reason is that on
    Intel, the DRTM log is not initialized by TrenchBoot code in the
    preamble. It is only responsible for allocating a buffer and recording
    the location in the TXT structures. When the SINIT ACM is executed, it
    will initialize the log and record the measurement that CPU sent
    directly to the TPM and then the measurements the ACM makes of the
    environment. If you pointed at the SRTM log, then the ACM would write
    over existing log, which I don't think you want. Now if you pointed at
    the tail end of the SRTM log, you would still end up with a second,
    separate log that just happens to be memory adjacent. The second reason
    is more from a trusted computing perspective, these are two different
    trust chains starting from two different Roots of Trust reflecting two
    different temporal states of the system, i.e. freshness. Typically this
    is were most will point out the need to have a measure of the resident
    firmware, i.e. SMM. To address that, should Intel to publish the spec
    for interacting with PPAM[1], TrenchBoot will be able to finally close
    the SMM gap, giving runtime validation of SMM.

    [1]
    https://www.intel.com/content/dam/www/central-libraries/us/en/documents/drtm-based-computing-whitepaper.pdf

    v/r,
    dps

    \
     
     \ /
      Last update: 2023-05-16 03:12    [W:7.940 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site