On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote: > Hi Paul! /me waves > On 11/30/21 8:06 PM, Paul Moore wrote: > > 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) ... > > No worries, thank you so much for taking the time to review. > > >> 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? > > That is correct. > > > 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? > > The TrenchBoot model is a bit different and takes a more flexible > approach to allow users to build tailored solutions. For instance Secure > Launch is able to be used in a configuration that is similar to tboot. > Consider the functions of tboot, it has a portion that is the > post-launch kernel that handles the handover from the ACM and a portion > that provides the Verified Launch policy engine, which is only capable > of enforcing policy on what is contained in the Multiboot chain. The > TrenchBoot approach is to introduce the Secure Launch capability into a > kernel, in this case Linux, to handle the handover from the ACM, and > then transition to a running user space that can contain a distribution > specific policy enforcement. As an example, the TrenchBoot project > contributed to the uroot project a Secure Launch policy engine which > enables the creation of an initramfs image which can then be embedded > into a minimal configuration Secure Launch Linux kernel ... Thank you for the answers, that was helpful. I think I initially misunderstood TrenchBoot, thinking that a Secure Launch'd kernel/userspace would be the "normal" OS that would transition to multi-user mode and be available for users and applications. However, on reading your response it appears that the Secure Launch'd kernel/initramfs exists only to verify a secondary kernel/initramfs/userspace and then kexec() into that once verified. > Finally if your schedule allows it and it is not too much to ask, it > would be greatly appreciated if some code review could be provided. > Otherwise thank you for taking the time that you have to review the > approach. I have to admit that I'm not sure I'm the most appropriate person to review all of the Intel TXT related assembly, but I could give it a shot as time allows. I would think Intel would be willing to help out here if one were to ask nicely :) Beyond that, and with my new understanding of how TrenchBoot is supposed to work, I guess my only other concern is how one might verify the integrity of the Secure Launch environment on the local system during boot. My apologies if I missed some details about that in your docs, responses, etc. but is this something that TrenchBoot is planning on addressing (or has already addressed)? -- paul moore www.paul-moore.com
