On Mon, Dec 6, 2021 at 3:56 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > 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)? I wanted to follow-up on this thread just in case this last question was lost ... -- paul moore paul-moore.com
