Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support

[Daniel P. Smith]

On 3/25/20 6:51 PM, Andy Lutomirski wrote:
> On Wed, Mar 25, 2020 at 1:29 PM Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
>>
>> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
>> <ross.philipson@xxxxxxxxxx> wrote:
>>> To enable the kernel to be launched by GETSEC or SKINIT, a stub must be
>>> built into the setup section of the compressed kernel to handle the
>>> specific state that the late launch process leaves the BSP. This is a
>>> lot like the EFI stub that is found in the same area. Also this stub
>>> must measure everything that is going to be used as early as possible.
>>> This stub code and subsequent code must also deal with the specific
>>> state that the late launch leaves the APs in.
>>
>> How does this integrate with the EFI entry point? That's the expected
>> entry point on most modern x86. What's calling ExitBootServices() in
>> this flow, and does the secure launch have to occur after it? It'd be
>> a lot easier if you could still use the firmware's TPM code rather
>> than carrying yet another copy.
> 
> I was wondering why the bootloader was involved at all.  In other
> words, could you instead hand off control to the kernel just like
> normal and have the kernel itself (in normal code, the EFI stub, or
> wherever it makes sense) do the DRTM launch all by itself?  This would
> avoid needing to patch bootloaders, to implement this specially for
> QEMU -kernel, to get the exact right buy-in from all the cloud
> vendors, etc.  It would also give you more flexibility to evolve
> exactly what configuration maps to exactly what PCRs in the future.
> 

Partly this is driven by the fact that one of the goals for the
TrenchBoot project is about more universal/unified, cross open source
project adoption of Dynamic Launch. Another aspect is that initiating a
Dynamic Launch requires additional file(s) to be loaded, the platform to
be put into a quiescent state, and the invocation of the SENTER/SKINIT
instruction can be thought of as a soft reset of the CPU that on Intel
even results in the CPU being in a different mode (SMX) which has a
subtle change to its behavior. In the TCG Dynamic Launch design, the
component responsible for this loading, preparing, and Dynamic Launch
Instruction invocation is referred to as the Preamble and IMHO the best
time for dealing with such a disruptive behavior caused by invoking the
instruction is at the boot boundary. It also makes for a good transition
point to enable switching between kernels in control of the system
whereby the integrity will be establish by the hardware instead of the
kernel (UEFI, GRUB, Linux, etc.) that loaded it. I think what helps
address your concern is that one of the next items on the roadmap is to
extend kexec to be able to perform the Preamble. As I just mentioned,
this provides a clean way to transition for one Linux kernel that may or
may not have been started via a Dynamic Launch could relaunch itself,
launch a new Linux kernel, or even launch a non-Linux kernel that is
Dynamic Launch aware.

As for controlling which PCRs are used, the ability to control that is
actually quite limited. The CPU will always put its first measurement
into PCR 17 and then next set of measurement will differ depending on
whether you are on Intel or AMD. With Intel, the Intel provided binary
blob called the ACM has a fixed measurement policy it uses to place
measurements into PCRs 17 and 18. On AMD they left their ACM equivalent
as an exercise for the implementer (for which we have one in
development) which give us control over the measurements that it takes.
Then you have to consider the properties of the DRTM PCRs, 17-22, where
PCRs 17, 18, and 19 are the only ones that cannot be reset after the
DRTM event. Where as PCRs 20, 21, 22 can be reset by Locality 2, the
highest locality for which the kernel will be able to request/access.

I hope this helps and if you have any other questions concerns I would
be glad to answer them.

V/r,
Daniel P. Smith