Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support

[Paul Moore <paul@paul-moore.com>]

On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith
<dpsmith@apertussolutions.com> 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@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) ...
>
> 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