Re: Linux DRTM on UEFI platforms
Hi Matt, On Tue, 29 Mar 2022 at 19:41, Matthew Garrett wrote: > > We're still trying to come to a conclusion about the most maintainable > approach to getting DRTM implementations like Intel TXT working on UEFI > platforms under Linux. I'm going to try to summarise the situation here > - I'm not an expert, so details may be inaccurate, but I think this is > the rough shape of things. > > Under normal circumstances on UEFI platforms, the bootloader (or system > firmware directly) load the kernel and execute code in the boot stub. > This boot stub code interacts with the firmware in various ways, > including working around some platform-specific issues and doing things > like copying the TPM event log into memory that can be used by the > kernel proper. While it remains technically possible to boot the kernel > on x86 UEFI platforms by jumping directly to the kernel entry point and > skipping the boot stub, this risks disabling certain functionality and > leaving the kernel in a slightly unexpected state. The contract that > exists between the UEFI stub and the kernel is not meaningfully > documented - portions are carried out by updating the contents of the > bootparams struct on x86 or devicetree on ARM, but other information is > conveyed via UEFI configuration tables, the boot stub may modify the > contents of certain UEFI variables, and some of this is implicit in > the form of hardware state. > > The Trenchboot project is attempting to implement DRTM under Linux. > Traditional measured boot takes the form of a static root of trust - > each component in the boot chain is measured by the previous component > before being executed, and each measures what it considers to be > security relevant configuration and behavioural state. Modifying any > component will change the measurements, even if the end result is > equivalent. Dynamic Root of Trust Measurement aims to provide more > useful measurements by performing a measurement at a specific point in > time - as a result, DRTM cares only about what the state *is*, not what > happened before then. > > There's a bunch of complexity involved in this that's vendor specific, > but the short version is that a launch environment is set up and a > specific CPU instruction executed that triggers a secure launch event. > The Trenchboot code consists of patches to bootloaders to support > setting up this environment, and patches to the kernel to provide > support for the "Secure Launch" kernel that handles DRTM before handing > control off to the kernel proper, skipping the UEFI boot stub. > > Since this skips the UEFI boot stub, it's then the responsibility of the > bootloader to implement the functionality of the boot stub. This is made > difficult due to the absence of an express contract between the boot > stub and the rest of the kernel - our assumption has been that the code > is the contract, and this is free to change arbitrarily since both the > producer and the consumer of the information can be updated > simultaneously and can't get out of sync. That seems to leave us with > two options: > > 1) Formalise the contract between the boot stub and the kernel, making > it easier for other boot loaders to implement the contract. This has the > downside that even within the scope of the contract we may end up with > divergent behaviour, and also new functionality in the kernel may not be > available without the bootloader also being updated. > > 2) Modify the boot stub such that it can be provided with a callback, > and instead of jumping to the kernel it can jump to the callback. The > boot flow would then involve the boot loader setting up the launch > environment, calling the boot stub code, and then performing the DRTM > event. This avoids requiring an explicit contract (the boot stub would > remain part of the kernel image and would be updated in lockstep). > > One complexity for both approaches is that the secure launch environment > needs to be aware of all security-critical state in the system. The > firmware nominally exposes that information for everything it's aware > of that's security-critical, but the boot stub may have performed > security-critical actions or exposed security-critical state that the > firmware is unaware of. The secure launch code from Trenchboot has to be > aware of this in order to ensure it's measured. > > If there's a contract, then in theory this would be embodied in the > contract and when the contract is updated the secure launch code could > also be updated. If there's no contract, every change to the boot stub > would need to be examined and the secure launch code updated if > necessary. > > While the secure launch code is currently out of tree, the goal is for > it to be integrated into the kernel tree. My feeling is that it's > going to be easier to manage this if everything is in tree - ie, all the > EFI setup code that does anything security-critical is either in the > firmware (and so the firmware takes responsibility
Re: Linux DRTM on UEFI platforms
On Wed, Mar 30, 2022 at 09:02:18AM +0200, Ard Biesheuvel wrote: > Wouldn't it be better for the secure launch kernel to boot the EFI > entrypoint directly? As it happens, I just completed a PoC last week > for a minimal implementation of EFI (in Rust) that only carries the > pieces that the EFI stub needs to boot Linux. It is currently just a > proof of concept that only works on QEMU/arm64, but it should not be > too hard to adapt it for x86 and for booting a kernel that has already > been loaded to memory. The EFI stub carries out a bunch of actions that have meaningful security impact, and that's material that should be measured. Having the secure launch kernel execute the stub without awareness of what it does means it would need to measure the code without measuring the state, while the goal of DRTM solutions is to measure state rather than the code. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
On Wed, 30 Mar 2022 at 09:11, Matthew Garrett wrote: > > On Wed, Mar 30, 2022 at 09:02:18AM +0200, Ard Biesheuvel wrote: > > > Wouldn't it be better for the secure launch kernel to boot the EFI > > entrypoint directly? As it happens, I just completed a PoC last week > > for a minimal implementation of EFI (in Rust) that only carries the > > pieces that the EFI stub needs to boot Linux. It is currently just a > > proof of concept that only works on QEMU/arm64, but it should not be > > too hard to adapt it for x86 and for booting a kernel that has already > > been loaded to memory. > > The EFI stub carries out a bunch of actions that have meaningful > security impact, and that's material that should be measured. Having the > secure launch kernel execute the stub without awareness of what it does > means it would need to measure the code without measuring the state, > while the goal of DRTM solutions is to measure state rather than the > code. But how is that any different from the early kernel code? ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote: > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett wrote: > > The EFI stub carries out a bunch of actions that have meaningful > > security impact, and that's material that should be measured. Having the > > secure launch kernel execute the stub without awareness of what it does > > means it would need to measure the code without measuring the state, > > while the goal of DRTM solutions is to measure state rather than the > > code. > > But how is that any different from the early kernel code? From a conceptual perspective we've thought of the EFI stub as being logically part of the bootloader rather than the early kernel, and the bootloader is a point where the line is drawn. My guy feeling is that jumping into the secure kernel environment before EBS has been called is likely to end badly. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
On Wed, 30 Mar 2022 at 09:19, Matthew Garrett wrote: > > On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote: > > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett wrote: > > > The EFI stub carries out a bunch of actions that have meaningful > > > security impact, and that's material that should be measured. Having the > > > secure launch kernel execute the stub without awareness of what it does > > > means it would need to measure the code without measuring the state, > > > while the goal of DRTM solutions is to measure state rather than the > > > code. > > > > But how is that any different from the early kernel code? > > From a conceptual perspective we've thought of the EFI stub as being > logically part of the bootloader rather than the early kernel, and the > bootloader is a point where the line is drawn. My guy feeling is that > jumping into the secure kernel environment before EBS has been called is > likely to end badly. If you jump back into the system firmware, sure. But the point I was trying to make is that you can replace that with your own minimal implementation of EFI that just exposes a memory map and some protocols and nothing else, and then the secure launch kernel would be entirely in charge of the execution environment. In fact, I have been experimenting with running the EFI stub unprivileged on arm64, which would give the secure launch kernel very tight control over what goes on between the stub entry and ExitBootServices(). I would be happy to entertain patches that remove any issues that complicate running the stub unprivileged for x86 or other architectures. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett wrote: > > From a conceptual perspective we've thought of the EFI stub as being > > logically part of the bootloader rather than the early kernel, and the > > bootloader is a point where the line is drawn. My guy feeling is that > > jumping into the secure kernel environment before EBS has been called is > > likely to end badly. > > If you jump back into the system firmware, sure. > > But the point I was trying to make is that you can replace that with > your own minimal implementation of EFI that just exposes a memory map > and some protocols and nothing else, and then the secure launch kernel > would be entirely in charge of the execution environment. We can't just replace system firmware with an imitation of the same - for instance, configuring the cold boot prevention memory overwrite requires us to pass a variable through to the real firmware, and that's something that we do in the stub. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
On Wed, 30 Mar 2022 at 09:27, Matthew Garrett wrote: > > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett wrote: > > > From a conceptual perspective we've thought of the EFI stub as being > > > logically part of the bootloader rather than the early kernel, and the > > > bootloader is a point where the line is drawn. My guy feeling is that > > > jumping into the secure kernel environment before EBS has been called is > > > likely to end badly. > > > > If you jump back into the system firmware, sure. > > > > But the point I was trying to make is that you can replace that with > > your own minimal implementation of EFI that just exposes a memory map > > and some protocols and nothing else, and then the secure launch kernel > > would be entirely in charge of the execution environment. > > We can't just replace system firmware with an imitation of the same - > for instance, configuring the cold boot prevention memory overwrite > requires us to pass a variable through to the real firmware, and that's > something that we do in the stub. > But these are exactly the kinds of things the secure launch kernel wants to be made aware of, no? The secure launch kernel could just MITM the calls that it chooses to allow, and serve other calls itself. But more fundamentally, I am failing to see the distinction here between stub code and other kernel code. Is it related to the exact moment the secure launch event is triggered? The way I see it, being able to marshall everything that goes on between the stub and the secure launch kernel allows the latter to make an informed decision about how the stub has manipulated the global system state before triggering the secure launch event at exitbootservices time. But perhaps my mental model is simply too inaccurate - it would be helpful to understand what exactly needs to be locked down, and what aspects of the system state are of interest for the DRTM measurements. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
On Wed, 2022-03-30 at 09:39 +0200, Ard Biesheuvel wrote: > On Wed, 30 Mar 2022 at 09:27, Matthew Garrett > wrote: > > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett < > > > mj...@srcf.ucam.org> wrote: > > > > From a conceptual perspective we've thought of the EFI stub as > > > > being logically part of the bootloader rather than the early > > > > kernel, and the bootloader is a point where the line is drawn. > > > > My guy feeling is that jumping into the secure kernel > > > > environment before EBS has been called is likely to end badly. > > > > > > If you jump back into the system firmware, sure. > > > > > > But the point I was trying to make is that you can replace that > > > with your own minimal implementation of EFI that just exposes a > > > memory map and some protocols and nothing else, and then the > > > secure launch kernel would be entirely in charge of the execution > > > environment. > > > > We can't just replace system firmware with an imitation of the same > > - for instance, configuring the cold boot prevention memory > > overwrite requires us to pass a variable through to the real > > firmware, and that's something that we do in the stub. > > > > But these are exactly the kinds of things the secure launch kernel > wants to be made aware of, no? The secure launch kernel could just > MITM the calls that it chooses to allow, and serve other calls > itself. The problem would become that the MITM firmware has to be evolved in lockstep with the boot stub. The problem isn't really a point in time, figure out what config the boot stub extracts from EFI now and measure it, it's an ongoing one: given an evolving kernel and UEFI subsystem means that over time what configuration the kernel extracts from EFI changes, how do we make sure it's all correctly measured before secure launch? If the MITM doesn't support a capability a newer kernel acquires, that MITM must fail secure launch ... which becomes a nightmare for the user. One possibility might be that the MITM actually does nothing at all except record Boot Service requests and responses up to exit boot services (EBS). We could call that record the boot configuration and measure it, plus we could then intercept EBS, and do the DRTM secure launch to the return point. It's conceptually similar Matthew's idea of a callback except it won't require modification of the boot parameters. James ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Linux DRTM on UEFI platforms
Greetings Matthew, First thank you to you and James for taking time out of your busy schedules to sit down with us and work through all of this. Hey Ard, On 3/30/22 03:02, Ard Biesheuvel wrote:>> 1) From an EFI maintainer perspective, is making the contract between >> the boot stub and the kernel explicit viable? >> > > No. The direction of travel has been to define EFI boot only in terms > of the handover from the loader to the stub. What happens next is up > to the architecture, and is deliberately not specified, because it is > considered to be internal Linux ABI. We've deviated from this once for > Xen on ARM, but this means we have already painted ourselves into a > corner when it comes the way we use DT internally at the handover > point between stub and kernel proper, and I am not eager to repeat > that. Locking down the stub-to-kernel protocol for all architectures > is not the way to go. To help provide some visual context, for EFI today there is, bzImage [EFI boot manager] -> [[efi-stub] -> [setup kernel] -> [main kernel]] Where the efi-stub is responsible for interacting with firmware to configure the system, store that configuration for the setup kernel and the main kernel, and then call EBS before entering the setup kernel. For Secure Launch the flow (on Intel) is, CPU instruction bzImage [preamble] -> [ACM] -> [[sl-stub] -> [setup kernel] -> [main kernel]] In order to make the CPU instruction call to enter the ACM the system must be in a very specific quiescent state. This includes but not exhaustively, * EBS must have been called * TPM should have all localities closed * IOMMU PMRs must be programmed appropriately * TXT heap space allocated * TXT heap space populated with config structures * All APs must be in a specific idle state * Execution is on the BSP Carrying all this out is what is considered the DRTM preamble. This is the wrinkle because the setup kernel and main kernel are both predicated on the efi-stub and the efi-stub is predicated on running before EBS. So how can this wrinkle be addressed? The TrenchBoot project proposed that the information collected by the efi-stub be formally documented for two reasons, 1. to allow the sl-stub to be aware of what and where all external data is being injected into the kernel so any data that may be security critical could be measured, and 2. it would allow third parties, e.g. GRUB, could correctly configure the system, pass all EFI related information correctly to the setup kernel and the main kernel before executing the preamble. Where the former is more of a concern than enabling the latter. Relating to what information is security critical, this can be a bit subjective. For example Dave Weston has a twitter thread[1][2][3] over what state Azure Attestation can validate for a DRTM Windows system. This reflects what Microsoft believes it's customers will want to validate about a Windows system before accessing services and data stored in Azure. For Linux Secure Launch measuring everything would obviously provide the finest grain of assertions regarding how the kernel was configured to run but that comes at the expense that is incurred for taking the measurements. To date the selection of measurements have been an attempt of balancing the most meaningful measurements with how many measurements should be taken. For instance it would be possible to hash the SRTM (firmware) TPM event log to provide an assertion of what its contents were at dynamic launch. Is that a meaningful measurement? Not necessarily since there are other means to validate the log but there is likely someone who is super cautious and would like to see the extra layer of validation. >> 2) If so, is it desirable? >> >> 3) If either (1) or (2) is "no", is it reasonable to ensure that all >> potentially security-critical state or configuration changes to the >> boot stub are reviewed by DRTM people to verify whether the secure >> launch code needs to be updated to match? > > Wouldn't it be better for the secure launch kernel to boot the EFI > entrypoint directly? As it happens, I just completed a PoC last week > for a minimal implementation of EFI (in Rust) that only carries the > pieces that the EFI stub needs to boot Linux. It is currently just a > proof of concept that only works on QEMU/arm64, but it should not be > too hard to adapt it for x86 and for booting a kernel that has already > been loaded to memory. IIUC, as you can see above, entering the efi-stub from the dynamic launch will fail because EBS will have been called. v/r, dps [1] https://twitter.com/dwizzzlemsft/status/1508517758635446273 [2] https://twitter.com/dwizzzlemsft/status/1508602527482146816 [3] https://twitter.com/dwizzzlemsft/status/1508852935261794312 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
