lkml.org 
[lkml]   [2021]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
    On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson
    <ross.philipson@oracle.com> wrote:
    >
    > The larger focus of the Trechboot project (https://github.com/TrenchBoot) is to
    > enhance the boot security and integrity in a unified manner. The first area of
    > focus has been on the Trusted Computing Group's Dynamic Launch for establishing
    > a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root of
    > Trust for Measurement).

    My apologies for such a late reply, but I'm just getting around to
    looking at this and I have a few questions on the basic design/flow
    (below) ...

    > The basic flow is:
    >
    > - Entry from the dynamic launch jumps to the SL stub

    So I'm clear, at this point the combined stub+kernel+initramfs+cmdline
    image has already been loaded into memory and the SL stub is
    executing, yes?

    As TrenchBoot seems to be focused on boot measurement and not
    enforcing policy, I'm guessing this is considered out-of-scope (not to
    mention that the combined stub+kernel image makes this less
    interesting), but has any thought been given to leveraging the TXT
    launch control policy, or is it simply an empty run-everything policy?

    > - SL stub fixes up the world on the BSP
    > - For TXT, SL stub wakes the APs, fixes up their worlds
    > - For TXT, APs are left halted waiting for an NMI to wake them
    > - SL stub jumps to startup_32
    > - SL main locates the TPM event log and writes the measurements of
    > configuration and module information into it.

    Since the stub+kernel image are combined it looks like the kernel
    measurement comes from the ACM via the MLE measurement into PCR 18,
    while the stub generated measurements are extended into PCR 19 or 20
    depending on the configuration, yes?

    I realize that moving the TXT code into the kernel makes this
    difficult (not possible?), but one of the things that was nice about
    the tboot based approach (dynamic, early launch) was that it could be
    extended to do different types of measurements, e.g. a signing
    authority measurement similar to UEFI Secure Boot and PCR 7. If that
    is possible, I think it is something worth including in the design,
    even if it isn't initially implemented. The only thing that
    immediately comes to mind would be a section/region based approach
    similar to systemd-boot/gummiboot where the (signed) kernel is kept in
    a well known region and verified/measured by the stub prior to jumping
    into its start point.

    > - Kernel boot proceeds normally from this point.
    > - During early setup, slaunch_setup() runs to finish some validation
    > and setup tasks.
    > - The SMP bringup code is modified to wake the waiting APs. APs vector
    > to rmpiggy and start up normally from that point.
    > - SL platform module is registered as a late initcall module. It reads
    > the TPM event log and extends the measurements taken into the TPM PCRs.

    I'm sure there is some issue with passing data across boundaries, but
    is there any reason why the TPM event log needs to be updated
    out-of-sync with the TPM PCRs? Is is possible to pass the
    measurements to the SL platform module which would both extend the
    PCRs and update the TPM event log at the same time?

    > - SL platform module initializes the securityfs interface to allow
    > asccess to the TPM event log and TXT public registers.
    > - Kernel boot finishes booting normally
    > - SEXIT support to leave SMX mode is present on the kexec path and
    > the various reboot paths (poweroff, reset, halt).

    It doesn't look like it's currently implemented, but it looks like
    eventually you plan to support doing a new DRTM measurement on kexec,
    is that correct? I'm sure that is something a *lot* of people
    (including myself) would like to see happen.

    --
    paul moore
    www.paul-moore.com

    \
     
     \ /
      Last update: 2021-12-01 02:08    [W:4.437 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site