On Thu, 19 May 2022 at 22:59, Daniel P. Smith
wrote:
>
>
> Greetings,
>
> Based on the discussions that occurred in this thread, there seems to be
> two issues at hand that should be decoupled, as their solutions can and
> should be implemented independently. These are:
> - the handling of the Dynamic Launch preamble
> - providing the complete kernel configuration for measurement
>
> For the former, it is believed there is a consensus that Matthew's
> proposed callback approach would be the preferred method. Through some
> contemplating and prototyping, the determination is that this will in
> fact be an approach that will ultimately benefit the TrenchBoot project
> itself.
>
> In general, the preamble consists of two activities: 1. preparing the
> contents in memory and 2. preparing the hardware in order to call the
> Dynamic Launch instruction. In past implementations, these two
> activities were conducted sequentially, but in reality the time delta
> between the two may be arbitrary. Introducing this separation does not
> introduce any security concerns due to how the Dynamic Launch works. Any
> tampering of the contents in memory will either cause the Dynamic Launch
> to fail or result in a detectable difference in the Dynamic Launch
> measurement chain.
>
> In order to separate the hardware interactions into what will be called
> the DLE Handler, this will require a collection of information regarding
> how the environment is set up. When working through what would be
> required, this led to the realization that this really should be
> generalized into a formal specification for TrenchBoot's Secure Launch.
> This will enable a reusable solution for the TrenchBoot project, versus
> implementing a one-off solution for Linux. A prototype of is near
> completion, for which below is a visual depiction along with a
> step-by-step walk through of how it would work for efi-stub.
>
> Secure Launch Flow:
>
> +-+
> | |
> +-->| Secure Launch +---+
> | | Resource Table | |
> | | |+--|---+
> | +++| | DLME |
> || | v |
> || | +---+|
>+-+-+ v | | ||
> +--+-+ | +-+ | | Secure Launch ||
> || +-->| +--->| Entry ||
> | Bootloader(s) | | | DLE Handler | | | ||
> |+-+ | | | +---+|
> ++ +-+ +--+
>
> A quick note on the flow diagram, for simplicity all entities prior to
> the DLE Handler are represented by the "Bootloader(s)" block due to the
> fact that what entities are involved can and will vary. This is where
> both GRUB and efi-stub are being represented even though for Linux EFI,
> GRUB is considered the bootmanager while efi-stub is the bootloader.
>
> An efi-stub walk-thru:
>
> 1. - GRUB
> 1.1 - GRUB will initialize the Secure Launch Resource Table (SLRT)
> 1.2 - GRUB will set up DLE Handler and register it in SLRT
> 1.5 - GRUB will load Linux kernel
> 1.3 - GRUB will set up DL environment appropriately for HW platform
> 1.4 - GRUB will record DL setup in SLRT
> 1.5 - GRUB will record SLRT location in platform's DL config structure
> 1.5 - GRUB will register SLRT in EFI configuration table under SL GUID
> 1.6 - GRUB will invoke efi-stub
>
> 2. - efi-stub
> 2.1 - efi-stub will check if SL GUID is in EFI configuration table
> 2.2 - for each efi-stub config action, an SLRT EFI config event will be
> recorded
> 2.3 - efi-stub calls EBS() then jumps to DLE Handler registered in SLRT
> while passing the SLRT address
>
> 3. - DL Handler
> 3.1 - DL Handler will retrieve SL Entry from SLRT
> 3.2 - DL Handler will prepare HW for calling DL CPU instruction
> 3.3 - DL Handler will execute DL CPU instruction
>
> 4. SL Entry
> 4.1 SL Entry will retrieve SLRT address from platform's DL config struct
> 4.2 SL Entry will use policy in SLRT to determine what to measure
> 4.3 SL Entry will set up HW to what Linux expects
> 4.4 SL Entry will jump into Linux setup kernel
> 4.5 SL Entry will record measurements into TPM prior to init process
> starting
>
> While Matthew's original proposal was around having a location in the
> efi-stub for the callback to be registered, it is felt that it would be
> better suited as part of the Secure Launch specification. What is
> proposed is for the address of the DL Handler to be stored in the SLRT,
> details for the SLRT are below. Then the bootloader that is responsible
> for loading the DL Handler will regi
