On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson <ross.philipson@xxxxxxxxxx> 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
