Paul, Apologies for missing your follow-up questions. Hopefully, the below answers will help. On 1/21/22 16:39, Paul Moore wrote: > 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. Yes it can be used in this manner but this is not the only way it was intended to be used. The goal is to enable an integrator, e.g, a distro, to incorporate Linux Secure Launch appropriately for their security needs, though ideally it would be preferred that a standardized approach is adopted by Linux init tooling to provide common experience across distros. Up until the introduction of Secure Launch, the only widely deployed model for DRTM has been to use tboot. Tboot is an MLE/DLME that functions as an exokernel and an intermediate loader for the Runtime OS/MLE. This motivated the first exemplar solution to be a Linux Secure Launch + uroot solution that would provide a similar intermediate loader experience, but with an expanded ability of the uroot to measure additional properties about a system. As a result a distro could use the exemplar to replace tboot, tboot VL policy tools, and VL policy file with a Secure Launch kernel, a u-root initrd (built-in or standalone), and a JSON policy file. By no means was Secure Launch meant to be limited to only being used as an intermediate loader for a Runtime OS. There is nothing that prohibits a Runtime Linux system to be directly started using Secure Launch. Though it should be noted that such a solution would need to be cognizant of the security gap across power-save modes, whereby the OS looses the positive control that it had over the system. It should also be mentioned that one of the motivations behind DRTM late-launch via kexec is to provide a path for dealing with this gap by enabling a late-launch to re-establish a known good state of the system. These all can be considered the advanced use cases for Secure Launch. >>> 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 ... To continue from the answer above and lead into answering your question I would first point to a presentation I gave at LPC 2020, Advanced Applications of DRTM with TrenchBoot[1]. There I walked through how Secure Launch could be used for different early-launch and late-launch DRTM solutions. Under the late-launch solutions there is the "Secure Upgrade" solutions. What I laid out there is that DRTM could be used to launch an "Upgrade Environment" which could be locally or remotely verified and provide a known-good and clean environment to upgrade a system. What an implementation of that actually looks like can be seen in the presentation by Brain Payne and myself at FOSDEM 2021, Secure Upgrades with DRTM[2]. In this presentation the concept of a Management MLE is introduced to provide a secure means to upgrade the Runtime MLE along with its related policy and sealing measurements. Now the above, like most local verification, relies on the unseal operation as the means of local attestation. Using unseal is strong but the reality is that remote attestation is stronger. The problem is that remote attestation is often built as an enterprise solutions requiring a central server/service under the control of an authority that decides what is good or bad. Often the average user either does not have access to such a service or does not desire to out-source control over their system. To address this I am collaborating with 3mdeb on their Fobnail product[3][4][5] to deliver an "attestation server in your pocket" capability that is accessible and usable by the average user. The answer so far is around solutions that were built from/around the TrenchBoot project but Linux Secure Launch does not require new, special user solutions. These solutions have been developed because DRTM enables them to exist, not that they are the only ways Linux Secure Launch can be utilized. For instance it is possible to setup a Clevis[6] based LUKS full disk encryption setup using clevis' TPM2 PIN, where the TPM2 PIN configuration uses the DRTM PCRs (17-22) as part of sealing PCRs for the encryption key. [1] https://lpc.events/event/7/contributions/739/ [2] https://archive.fosdem.org/2021/schedule/event/firmware_suwd/ [3] https://blog.3mdeb.com/2021/2021-10-28-fobnail-promotion/ [4] https://blog.3mdeb.com/2021/2021-12-15-fobnail_2nd_phase/ [5] https://fobnail.3mdeb.com/ [6] https://github.com/latchset/clevis V/r, Daniel P. Smith
