* Linux DRTM on UEFI platforms @ 2022-03-29 17:40 Matthew Garrett 2022-03-30 7:02 ` Ard Biesheuvel 2022-05-19 20:57 ` Daniel P. Smith 0 siblings, 2 replies; 32+ messages in thread From: Matthew Garrett @ 2022-03-29 17:40 UTC (permalink / raw) To: Daniel Kiper Cc: Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, grub-devel 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 for exposing it) or is in the Linux tree (and so we take responsibility for updating the secure launch code whenever something relevant changes in the boot stub). But this requires support from the EFI maintainers in terms of not merging things until we've established whether updates are required to the secure launch code. The alternative is effectively the same, except it would require updating the contract instead. But, as mentioned, that's just my feeling - I know that Daniel feels that the contract approach is preferable. So: 1) From an EFI maintainer perspective, is making the contract between the boot stub and the kernel explicit viable? 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? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-29 17:40 Linux DRTM on UEFI platforms Matthew Garrett @ 2022-03-30 7:02 ` Ard Biesheuvel 2022-03-30 7:11 ` Matthew Garrett 2022-03-31 0:35 ` Daniel P. Smith 2022-05-19 20:57 ` Daniel P. Smith 1 sibling, 2 replies; 32+ messages in thread From: Ard Biesheuvel @ 2022-03-30 7:02 UTC (permalink / raw) To: Matthew Garrett Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook Hi Matt, On Tue, 29 Mar 2022 at 19:41, Matthew Garrett <mjg59@srcf.ucam.org> 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 for exposing it) or > is in the Linux tree (and so we take responsibility for updating the > secure launch code whenever something relevant changes in the boot > stub). But this requires support from the EFI maintainers in terms of > not merging things until we've established whether updates are required > to the secure launch code. The alternative is effectively the same, > except it would require updating the contract instead. > > But, as mentioned, that's just my feeling - I know that Daniel feels > that the contract approach is preferable. So: > > 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. > 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. [0] https://github.com/ardbiesheuvel/efilite ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:02 ` Ard Biesheuvel @ 2022-03-30 7:11 ` Matthew Garrett 2022-03-30 7:12 ` Ard Biesheuvel 2022-03-31 0:35 ` Daniel P. Smith 1 sibling, 1 reply; 32+ messages in thread From: Matthew Garrett @ 2022-03-30 7:11 UTC (permalink / raw) To: Ard Biesheuvel Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:11 ` Matthew Garrett @ 2022-03-30 7:12 ` Ard Biesheuvel 2022-03-30 7:18 ` Matthew Garrett 0 siblings, 1 reply; 32+ messages in thread From: Ard Biesheuvel @ 2022-03-30 7:12 UTC (permalink / raw) To: Matthew Garrett Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <mjg59@srcf.ucam.org> 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? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:12 ` Ard Biesheuvel @ 2022-03-30 7:18 ` Matthew Garrett 2022-03-30 7:23 ` Ard Biesheuvel 0 siblings, 1 reply; 32+ messages in thread From: Matthew Garrett @ 2022-03-30 7:18 UTC (permalink / raw) To: Ard Biesheuvel Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote: > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <mjg59@srcf.ucam.org> 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:18 ` Matthew Garrett @ 2022-03-30 7:23 ` Ard Biesheuvel 2022-03-30 7:27 ` Matthew Garrett 0 siblings, 1 reply; 32+ messages in thread From: Ard Biesheuvel @ 2022-03-30 7:23 UTC (permalink / raw) To: Matthew Garrett Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote: > > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <mjg59@srcf.ucam.org> 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:23 ` Ard Biesheuvel @ 2022-03-30 7:27 ` Matthew Garrett 2022-03-30 7:39 ` Ard Biesheuvel 0 siblings, 1 reply; 32+ messages in thread From: Matthew Garrett @ 2022-03-30 7:27 UTC (permalink / raw) To: Ard Biesheuvel Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <mjg59@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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:27 ` Matthew Garrett @ 2022-03-30 7:39 ` Ard Biesheuvel 2022-03-30 12:46 ` James Bottomley 0 siblings, 1 reply; 32+ messages in thread From: Ard Biesheuvel @ 2022-03-30 7:39 UTC (permalink / raw) To: Matthew Garrett Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Wed, 30 Mar 2022 at 09:27, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <mjg59@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. 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:39 ` Ard Biesheuvel @ 2022-03-30 12:46 ` James Bottomley 0 siblings, 0 replies; 32+ messages in thread From: James Bottomley @ 2022-03-30 12:46 UTC (permalink / raw) To: Ard Biesheuvel, Matthew Garrett Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, dpsmith@apertussolutions.com, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Wed, 2022-03-30 at 09:39 +0200, Ard Biesheuvel wrote: > On Wed, 30 Mar 2022 at 09:27, Matthew Garrett <mjg59@srcf.ucam.org> > wrote: > > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett < > > > mjg59@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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-30 7:02 ` Ard Biesheuvel 2022-03-30 7:11 ` Matthew Garrett @ 2022-03-31 0:35 ` Daniel P. Smith 2022-03-31 7:13 ` Ard Biesheuvel 1 sibling, 1 reply; 32+ messages in thread From: Daniel P. Smith @ 2022-03-31 0:35 UTC (permalink / raw) To: Ard Biesheuvel, Matthew Garrett Cc: Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-31 0:35 ` Daniel P. Smith @ 2022-03-31 7:13 ` Ard Biesheuvel 2022-03-31 10:59 ` Heinrich Schuchardt 2022-05-19 20:57 ` Daniel P. Smith 0 siblings, 2 replies; 32+ messages in thread From: Ard Biesheuvel @ 2022-03-31 7:13 UTC (permalink / raw) To: Daniel P. Smith Cc: Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook On Thu, 31 Mar 2022 at 02:36, Daniel P. Smith <dpsmith@apertussolutions.com> wrote: > > 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. > Thanks for the explanation, this is really helpful. > 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. Matthew suggested this already, but can you explain why handling this in a callback is not an option? I'd by sympathetic to specifying a Linux specific protocol that can be grabbed before EBS() but can be invoked after (but not, say after SetVirtualAddressMap(), to keep things simple). That should allow us to call back into firmware to perform the secure launch right before handing over. My other suggestion, to use a minimal EFI environment just to boot the kernel, still seems viable to me as well, but it would boil down to mostly the same, thing, i.e., to inject an intermediate boot stage between the call to the firmware's EBS() and calling the entrypoint of the kernel proper. What I do like about this approach is that the EFI stub could execute unprivileged, which means the secure launch kernel could track *exactly* what the EFI stub is doing in terms of memory accesses and protocol invocations, which seems a bit more robust than the approximation of 'this might be interesting enough to measure' that the industry seems to have settled on. > 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. > The reason I am not willing to lock down the stub<->kernel boot protocol is because it doesn't scale: currently, the discussion is about x86, which is a bit different because we already so many ways to boot it, but for other architectures, this is going to create a huge maintenance burden: arm64, RISC-V and now LoongArch are all adding EFI boot support and are looking to support ACPI, SMBIOS and other features as well, and these are all gated on EFI boot, which requires booting via the stub. I'm not eager to kick this can down the road and go with something that inevitably implies either specifying and maintaining a whole array of internal protocols as external ABI, or revisiting this discussion and coming up with two different ways to do DRTM depending on whether you are running x86 or not. > 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. > So how will the above translate into meaningful and fair feedback in response to proposed changes to this documented stub<->kernel handover protocol, once the need arrives to make changes? Is this super cautious person going to be the one NAKing everything just because he is super cautious? Pardon the skepticism, but I am really reluctant to let this cat out of the bag if the requirements are so vague and there doesn't seem to consensus on the scope of DRTM. Another thing I missed is how these systems are supposed to carry out the tasks that the stub currently handles: Matt mentioned setting MemoryOverwriteRequest, but there is also TPM event log handling, and other bits and pieces. Are you saying this is all going to be part of this boot protocol as well? > >> 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. > I think you are missing my point here, tbh. What I am suggesting here is to run a separate, minimal EFI implementation, which has its own EBS() which is unrelated to the firmware one. Matthew pointed out some issues with this approach, but the fundamental idea is that it is just an impedance matcher that looks like EFI to the EFI stub, but is really just a loader with a memory map and some config tables. The requirement for this came up in the confidential computing space, but for bare metal, it seems having a tiny EFI-like shim that can only boot a Linux kernel (or other EFI-like payloads with no dependencies on the driver model or other UEFI/PI bloat) might be useful here as well, especially because it would be completely generic from the EFI side of things, as opposed to creating yet another project with intimate knowledge of struct bootparams, device trees, where in memory the kernel may be loaded on architecture X, where in memory the initrd may be loaded on architecture X, etc etc. So the bottom line is that we will have to make this work with EFI boot one way or the other, but skipping the EFI stub altogether is really not an option, unless you want to carry the burden of keeping your code in sync with the kernel. Locking this down as external ABI is not acceptable to me. Thanks, Ard. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-31 7:13 ` Ard Biesheuvel @ 2022-03-31 10:59 ` Heinrich Schuchardt 2022-05-19 20:57 ` Daniel P. Smith 1 sibling, 0 replies; 32+ messages in thread From: Heinrich Schuchardt @ 2022-03-31 10:59 UTC (permalink / raw) To: Ard Biesheuvel Cc: Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, Kees Cook, The development of GNU GRUB, Daniel P. Smith On 3/31/22 09:13, Ard Biesheuvel wrote: > On Thu, 31 Mar 2022 at 02:36, Daniel P. Smith > <dpsmith@apertussolutions.com> wrote: >> >> 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. >> > > Thanks for the explanation, this is really helpful. > >> 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. > > Matthew suggested this already, but can you explain why handling this > in a callback is not an option? I'd by sympathetic to specifying a The idea of the UEFI specification is that it is OS agnostic. So anything that is Linux-, Windows-, BSD-, etc. specific should not live in the UEFI firmware. If you want to implement any Linux specific extra protocol, you should implement it in Shim, GRUB, the kernel stub or any other UEFI binary loaded by the UEFI firmware but, please, don't rely on the UEFI firmware itself to implement it. If you are able to abstract the requirements for furthering secure boot in a way that is OS agnostic, then implementation in the UEFI firmware starts to make sense. But remember that there is a large installed base that is still lagging behind the current UEFI standard. Best regards Heinrich > Linux specific protocol that can be grabbed before EBS() but can be > invoked after (but not, say after SetVirtualAddressMap(), to keep > things simple). That should allow us to call back into firmware to > perform the secure launch right before handing over. > > My other suggestion, to use a minimal EFI environment just to boot the > kernel, still seems viable to me as well, but it would boil down to > mostly the same, thing, i.e., to inject an intermediate boot stage > between the call to the firmware's EBS() and calling the entrypoint of > the kernel proper. What I do like about this approach is that the EFI > stub could execute unprivileged, which means the secure launch kernel > could track *exactly* what the EFI stub is doing in terms of memory > accesses and protocol invocations, which seems a bit more robust than > the approximation of 'this might be interesting enough to measure' > that the industry seems to have settled on. > >> 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. >> > > The reason I am not willing to lock down the stub<->kernel boot > protocol is because it doesn't scale: currently, the discussion is > about x86, which is a bit different because we already so many ways to > boot it, but for other architectures, this is going to create a huge > maintenance burden: arm64, RISC-V and now LoongArch are all adding EFI > boot support and are looking to support ACPI, SMBIOS and other > features as well, and these are all gated on EFI boot, which requires > booting via the stub. > > I'm not eager to kick this can down the road and go with something > that inevitably implies either specifying and maintaining a whole > array of internal protocols as external ABI, or revisiting this > discussion and coming up with two different ways to do DRTM depending > on whether you are running x86 or not. > >> 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. >> > > So how will the above translate into meaningful and fair feedback in > response to proposed changes to this documented stub<->kernel handover > protocol, once the need arrives to make changes? Is this super > cautious person going to be the one NAKing everything just because he > is super cautious? > > Pardon the skepticism, but I am really reluctant to let this cat out > of the bag if the requirements are so vague and there doesn't seem to > consensus on the scope of DRTM. > > Another thing I missed is how these systems are supposed to carry out > the tasks that the stub currently handles: Matt mentioned setting > MemoryOverwriteRequest, but there is also TPM event log handling, and > other bits and pieces. Are you saying this is all going to be part of > this boot protocol as well? > >>>> 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. >> > > I think you are missing my point here, tbh. What I am suggesting here > is to run a separate, minimal EFI implementation, which has its own > EBS() which is unrelated to the firmware one. Matthew pointed out some > issues with this approach, but the fundamental idea is that it is just > an impedance matcher that looks like EFI to the EFI stub, but is > really just a loader with a memory map and some config tables. > > The requirement for this came up in the confidential computing space, > but for bare metal, it seems having a tiny EFI-like shim that can only > boot a Linux kernel (or other EFI-like payloads with no dependencies > on the driver model or other UEFI/PI bloat) might be useful here as > well, especially because it would be completely generic from the EFI > side of things, as opposed to creating yet another project with > intimate knowledge of struct bootparams, device trees, where in memory > the kernel may be loaded on architecture X, where in memory the initrd > may be loaded on architecture X, etc etc. > > So the bottom line is that we will have to make this work with EFI > boot one way or the other, but skipping the EFI stub altogether is > really not an option, unless you want to carry the burden of keeping > your code in sync with the kernel. Locking this down as external ABI > is not acceptable to me. > > Thanks, > Ard. > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-31 7:13 ` Ard Biesheuvel 2022-03-31 10:59 ` Heinrich Schuchardt @ 2022-05-19 20:57 ` Daniel P. Smith 1 sibling, 0 replies; 32+ messages in thread From: Daniel P. Smith @ 2022-05-19 20:57 UTC (permalink / raw) To: Ard Biesheuvel Cc: Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, Kees Cook Hey Ard, Apologies for the lag in response, I wanted to have this to you sooner, but between a variety of events and working on building consensus on how to address your comments made it drag out a little. Before reading this message, I would recommend reading the proposal posted to the top of this thread, as it details an approach that builds on Matthew's callback proposal along with addressing your concerns with measurements. In this message, I want to provide you direct answers to the points you raised independent of the reply at the top of this thread to help map where your concerns influenced the proposal. On 3/31/22 03:13, Ard Biesheuvel wrote: > On Thu, 31 Mar 2022 at 02:36, Daniel P. Smith > <dpsmith@apertussolutions.com> wrote: >> >> 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. >> > > Thanks for the explanation, this is really helpful. Your welcome. >> 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. > > Matthew suggested this already, but can you explain why handling this > in a callback is not an option? I'd by sympathetic to specifying a > Linux specific protocol that can be grabbed before EBS() but can be > invoked after (but not, say after SetVirtualAddressMap(), to keep > things simple). That should allow us to call back into firmware to > perform the secure launch right before handing over. Apologies, I was not meaning to suggest this was not an option. As you can see in the proposal posted, this approach is in fact being embraced. It is not explicit stated in the proposal, but the approach for the Secure Launch spec is to not explicitly dictate the location of the DL Handler. If a firmware manufacturer wants to implement a Secure Launch compliant DL Handler in firmware, this certainly would be welcomed, but should not be a requirement to enable Secure Launch. For instance, in the prototype the DL Handler is actually implemented as a stub in the setup kernel as that is the direction we are moving towards but may not be how the final implementation works. > My other suggestion, to use a minimal EFI environment just to boot the > kernel, still seems viable to me as well, but it would boil down to > mostly the same, thing, i.e., to inject an intermediate boot stage > between the call to the firmware's EBS() and calling the entrypoint of > the kernel proper. What I do like about this approach is that the EFI > stub could execute unprivileged, which means the secure launch kernel > could track *exactly* what the EFI stub is doing in terms of memory > accesses and protocol invocations, which seems a bit more robust than > the approximation of 'this might be interesting enough to measure' > that the industry seems to have settled on. IMHO that is the beauty of the Secure Launch spec. Just as you suggest, your EFI environment shim could track what the EFI stub does and record it in the SLRT. In addition, your shim could also implement the DL Handler to invoke the Dynamic Launch. >> 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. >> > > The reason I am not willing to lock down the stub<->kernel boot > protocol is because it doesn't scale: currently, the discussion is > about x86, which is a bit different because we already so many ways to > boot it, but for other architectures, this is going to create a huge > maintenance burden: arm64, RISC-V and now LoongArch are all adding EFI > boot support and are looking to support ACPI, SMBIOS and other > features as well, and these are all gated on EFI boot, which requires > booting via the stub. As I mentioned in the Secure Launch spec proposal, it was not correct for us to seek that the efi-stub<->kernel interface to be standardized. The reality is that Secure Launch is an entrypoint itself and like the efi-stub should provide an interface specifying how and what needs to be provided to it for it to function correctly. > I'm not eager to kick this can down the road and go with something > that inevitably implies either specifying and maintaining a whole > array of internal protocols as external ABI, or revisiting this > discussion and coming up with two different ways to do DRTM depending > on whether you are running x86 or not. Agreed, which is why we went back and worked on what is the proper way to address this problem. As has been mentioned many times, while x86 may have the most mature Dynamic Launch capability, it is not the only platform with Dynamic Launch. The goal for TrenchBoot is to provide a common experience, to the extent possible, for using Dynamic Launch across the different platforms that provide the capability. And to be clear, that is especially true for different environments on the same architecture. Specifically, we want setup and configuration to be the same on x86 coreboot and x86 UEFI. >> 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. >> > > So how will the above translate into meaningful and fair feedback in > response to proposed changes to this documented stub<->kernel handover > protocol, once the need arrives to make changes? Is this super > cautious person going to be the one NAKing everything just because he > is super cautious? There is only a mentioning of it in the proposal, but for the Secure Launch specification there will be a policy entry that will remove the need for having what will be measured codified in the kernel. It will allow measurement mechanisms to be implemented in the sl-stub and the policy will allow the selection and configuration of the mechanisms. > Pardon the skepticism, but I am really reluctant to let this cat out > of the bag if the requirements are so vague and there doesn't seem to > consensus on the scope of DRTM. I would say the scope is no less vague than it is for efi-stub. UEFI and kernel features will increase that will change the behavior of the kernel and affect its ability to protect information within the system. As this changes, DRTM will need to be able to measure this expansion so that it may be able to assert the system state/abilities to a user, a cloud or an enterprise. > Another thing I missed is how these systems are supposed to carry out > the tasks that the stub currently handles: Matt mentioned setting > MemoryOverwriteRequest, but there is also TPM event log handling, and > other bits and pieces. Are you saying this is all going to be part of > this boot protocol as well? This is no longer an issue with the new proposal. >>>> 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. >> > > I think you are missing my point here, tbh. What I am suggesting here > is to run a separate, minimal EFI implementation, which has its own > EBS() which is unrelated to the firmware one. Matthew pointed out some > issues with this approach, but the fundamental idea is that it is just > an impedance matcher that looks like EFI to the EFI stub, but is > really just a loader with a memory map and some config tables. I apologize, but I read "Wouldn't it be better for the secure launch kernel to boot the EFI entrypoint directly?" to mean that you would be looking for EFI entrypoint to be called by the Dyanmic Launch. If that is the case, then again I am not sure how you would make this work as is suggested. Let me clarify a little further on how Dynamic Launch hardware works. When the Dynamic Launch CPU instruction is called by the preamble, the system enters a new type of execution state, on Intel it is literally a separate CPU mode referred to as SMX. A very simplistic way to think of this is that the system has gone through a soft warm boot, but everything is now different. Instead of coming in through the reset vector, the system will jump to the DLME entrypoint that was registered during the preamble. There will be DMA protections in place protecting the regions specified during the preamble, and the CPU will function in a slightly different manner. For instance the AP rendezvous procedure has to be done differently, if a standard INIT-SIPI-SIPI rendezvous is attempted the system will fault. In the end, this is done to ensure to the best ability that the system is in a proper state and the only software executing is that which was measured by the CPU. It is a bit impressive what the CPU does, and for Intel CPUs there is a fair amount of detail documented under the SDM documentation for GETSEC[SENTER] [1]. This is one of the reasons there is a fair bit of assembly in the secure launch patch series, as there is a very specific way in which the system needs to be brought up from the minimal state it is left in by the GETSEC[SENTER] instruction to a state that the setup kernel is able to take control. This might be made to work by making this EFI shim capable of being entered by the Dynamic Launch and then call into the efi-stub. But tbh this is a non-starter from our perspective as this would then force all x86 environments to run this EFI shim, specifically coreboot environments. Just as Linux-EFI is not being pushed to work like a non-efi environment for Dynamic Launch, it would not be fair to force non-EFI environments to function like an EFI environment. As suggested above, under the Secure Launch spec proposal, the EFI shim would work very well as a preamble environment that implements the Secure Launch spec. [1] https://github.com/HJLebbink/asm-dude/wiki/GETSEC%5BSENTER%5D > The requirement for this came up in the confidential computing space, > but for bare metal, it seems having a tiny EFI-like shim that can only > boot a Linux kernel (or other EFI-like payloads with no dependencies > on the driver model or other UEFI/PI bloat) might be useful here as > well, especially because it would be completely generic from the EFI > side of things, as opposed to creating yet another project with > intimate knowledge of struct bootparams, device trees, where in memory > the kernel may be loaded on architecture X, where in memory the initrd > may be loaded on architecture X, etc etc. > > So the bottom line is that we will have to make this work with EFI > boot one way or the other, but skipping the EFI stub altogether is > really not an option, unless you want to carry the burden of keeping > your code in sync with the kernel. Locking this down as external ABI > is not acceptable to me. Agreed, which is why just as efi-stub has its entry interface that every bootmanager/bootloader must implement, the sl-stub is an entrypoint that will implement the Secure Launch specification for how it should be entered, whether that is by efi-stub or an EFI shim underneath efi-stub. V/r, Daniel P. Smith ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-03-29 17:40 Linux DRTM on UEFI platforms Matthew Garrett 2022-03-30 7:02 ` Ard Biesheuvel @ 2022-05-19 20:57 ` Daniel P. Smith 2022-06-10 16:40 ` Ard Biesheuvel 1 sibling, 1 reply; 32+ messages in thread From: Daniel P. Smith @ 2022-05-19 20:57 UTC (permalink / raw) To: Matthew Garrett, Daniel Kiper Cc: Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, grub-devel, James Morris 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 register the SLRT in the EFI configuration table. Checking for the SLRT GUID in the EFI configuration table will enable the EFI bootoader responsible for calling EBS, in this case efi-stub, to know that a Dynamic Launch has been requested. It also seems this would be more in line with how EFI tends to work, versus a Linux-specific callback boot param or something similar. Hopefully this resolves the first of the two issues mentioned at the beginning of this email in a manner that addresses most of the concerns raised in the earlier discussions. This leaves the second issue over how to get an accurate measurement of how the kernel was configured by efi-stub. When reviewing the comments in the discussion, it was realized the originally requested approach was in fact in reverse. Instead of asking for efi-stub's internal API/ABI to be documented, Secure Launch should specify an ABI for how any bootloader should be invoking a Secure Launch entrypoint, particularly capturing how an EFI bootloader configured the environment. This is the second motivation for devising the SLRT. Specifying this ABI also provided the opportunity to incorporate a measurement policy and thus allowing for it to be separated away from sl-stub, as it is in the current implementation. For this discussion the focus will be on the portions of the SLRT relating to EFI Environments and in particular the EFI config event record mentioned in step 2.2 of the efi-stub walk-thru. First, a short review of what the Secure Launch Resource Table is and its purpose. The SLRT is to provide a platform and kernel agnostic configuration table of the meta-data pertinent to the Secure Launch entry points for the variety of kernels the TrenchBoot project will be seeking to support. The specification for the table is in progress, but the consensus is that it will consist of a header structure followed by a packed series of TLV records. The specification will describe the various types of records, but the ones of interests in this discussion are those that efi-stub would use to record how it configured the environment. The initially proposed TLV record, see below, for EFI configuration information was devised around allowing an EFI bootloader to save multiple config events under a single TLV record. In discussions on the specification thus far, there are questions if it would be better to have a TLV record for each config event or the proposed multiple events per TLV record. It is worth noting that an assumption is being made in the proposed record. The assumption is that a config event will either be setting a configuration value between 1 and 8 bytes, or it will be a data blob for which the address and size will be recorded. The question is whether that covers all actions the efi-stub does or expects that it will have to do in the near future. struct slrt_entry_efi_config_event { struct slrt_entry_hdr hdr; uint32_t identifier; /* EFI bootloader ID */ uint16_t reserved; uint16_t nr_entries; /* Num cfg records */ struct efi_cfg_value values[0]; /* Array of cfg values */ }; struct efi_cfg_value { uint64_t data; /* cfg data (address or value) */ uint32_t size; /* data size if data is an addr */ uint32_t flags; /* 1L<0 IS_ADDR: data is an addr */ char evt_info[8]; /* event info str for TPM event log */ }; Hopefully the general approach here is agreeable, as IMHO it does provide a fairly elegant approach to resolving the issues at hand. Details can always be negotiated to address various implementation concerns. Provided this is acceptable, then everyone here is welcome to provide input on the Secure Launch specification, link forthcoming. V/r, Daniel P. Smith Apertus Solutions, LLC ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-05-19 20:57 ` Daniel P. Smith @ 2022-06-10 16:40 ` Ard Biesheuvel 2022-07-05 18:35 ` Daniel P. Smith 0 siblings, 1 reply; 32+ messages in thread From: Ard Biesheuvel @ 2022-06-10 16:40 UTC (permalink / raw) To: Daniel P. Smith Cc: Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, grub-devel, James Morris On Thu, 19 May 2022 at 22:59, Daniel P. Smith <dpsmith@apertussolutions.com> 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 register the SLRT in the EFI > configuration table. Checking for the SLRT GUID in the EFI configuration > table will enable the EFI bootoader responsible for calling EBS, in this > case efi-stub, to know that a Dynamic Launch has been requested. It also > seems this would be more in line with how EFI tends to work, versus a > Linux-specific callback boot param or something similar. > This all looks reasonable but it is not clear to me what a 'Linux setup kernel' is, and what the boot protocol is for that handover. The EFI stub to core kernel handover ABI is private to Linux, architecture specific, and subject to change. This is basically the point I made before: if you want to boot Linux in EFI mode, you have to go via the EFI stub, and the EFI stub is in charge of booting the kernel proper. This is why I (we?) suggested some kind of callback mechanism, where the EFI stub makes a D-RTM specific call after EBS(), but does regain control over the boot flow. If we add another entry point into the kernel proper for the Secure Launch Entry component to use, we are again exposing an internal ABI in a way that limits our future ability to make changes to the EFI <-> kernel handover. > Hopefully this resolves the first of the two issues mentioned at the > beginning of this email in a manner that addresses most of the concerns > raised in the earlier discussions. This leaves the second issue over how > to get an accurate measurement of how the kernel was configured by > efi-stub. When reviewing the comments in the discussion, it was realized > the originally requested approach was in fact in reverse. Instead of > asking for efi-stub's internal API/ABI to be documented, Secure Launch > should specify an ABI for how any bootloader should be invoking a Secure > Launch entrypoint, particularly capturing how an EFI bootloader > configured the environment. This is the second motivation for devising > the SLRT. Specifying this ABI also provided the opportunity to > incorporate a measurement policy and thus allowing for it to be > separated away from sl-stub, as it is in the current implementation. For > this discussion the focus will be on the portions of the SLRT relating > to EFI Environments and in particular the EFI config event record > mentioned in step 2.2 of the efi-stub walk-thru. > > First, a short review of what the Secure Launch Resource Table is and > its purpose. The SLRT is to provide a platform and kernel agnostic > configuration table of the meta-data pertinent to the Secure Launch > entry points for the variety of kernels the TrenchBoot project will be > seeking to support. The specification for the table is in progress, but > the consensus is that it will consist of a header structure followed by > a packed series of TLV records. The specification will describe the > various types of records, but the ones of interests in this discussion > are those that efi-stub would use to record how it configured the > environment. > > The initially proposed TLV record, see below, for EFI configuration > information was devised around allowing an EFI bootloader to save > multiple config events under a single TLV record. In discussions on the > specification thus far, there are questions if it would be better to > have a TLV record for each config event or the proposed multiple events > per TLV record. It is worth noting that an assumption is being made in > the proposed record. The assumption is that a config event will either > be setting a configuration value between 1 and 8 bytes, or it will be a > data blob for which the address and size will be recorded. The question > is whether that covers all actions the efi-stub does or expects that it > will have to do in the near future. > > struct slrt_entry_efi_config_event { > struct slrt_entry_hdr hdr; > uint32_t identifier; /* EFI bootloader ID */ > uint16_t reserved; > uint16_t nr_entries; /* Num cfg records */ > struct efi_cfg_value values[0]; /* Array of cfg values */ > }; > > struct efi_cfg_value { > uint64_t data; /* cfg data (address or value) */ > uint32_t size; /* data size if data is an addr */ > uint32_t flags; /* 1L<0 IS_ADDR: data is an addr */ > char evt_info[8]; /* event info str for TPM event log */ > }; > > Hopefully the general approach here is agreeable, as IMHO it does > provide a fairly elegant approach to resolving the issues at hand. > Details can always be negotiated to address various implementation > concerns. Provided this is acceptable, then everyone here is welcome to > provide input on the Secure Launch specification, link forthcoming. > Given that this is EFI, I would expect all these implementation details to be exposed via a protocol that the stub can invoke, in a way that will likely be similar (or the same?) as the TCG protocol used for recording PCR measurements. So could you elaborate on the types of actions? Is this simply things like the command line, initrd contents, initrd load address, kernel load address etc etc? There isn't generally that much going on in the stub beyond that. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-06-10 16:40 ` Ard Biesheuvel @ 2022-07-05 18:35 ` Daniel P. Smith 2022-07-06 0:03 ` Brendan Trotter 2022-08-05 12:53 ` Ard Biesheuvel 0 siblings, 2 replies; 32+ messages in thread From: Daniel P. Smith @ 2022-07-05 18:35 UTC (permalink / raw) To: Ard Biesheuvel Cc: Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, grub-devel, James Morris On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, Daniel P. Smith > <dpsmith@apertussolutions.com> wrote: >> >> >> Greetings, >> <snip/> >> 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 register the SLRT in the EFI >> configuration table. Checking for the SLRT GUID in the EFI configuration >> table will enable the EFI bootoader responsible for calling EBS, in this >> case efi-stub, to know that a Dynamic Launch has been requested. It also >> seems this would be more in line with how EFI tends to work, versus a >> Linux-specific callback boot param or something similar. >> > > This all looks reasonable but it is not clear to me what a 'Linux > setup kernel' is, and what the boot protocol is for that handover. I used the term 'Linux setup kernel' just to encapsulate the entrypoints, compressed kernel, and pre-"kernel proper" code. As for boot protocol, I believe the SLRT is what you are looking for, and we are in the process of drafting and verifying with a prototype. > The EFI stub to core kernel handover ABI is private to Linux, > architecture specific, and subject to change. This is basically the > point I made before: if you want to boot Linux in EFI mode, you have > to go via the EFI stub, and the EFI stub is in charge of booting the > kernel proper. This is why I (we?) suggested some kind of callback > mechanism, where the EFI stub makes a D-RTM specific call after EBS(), > but does regain control over the boot flow. Literally, this is not how the hardware works nor in line with the architecture developed by TrenchBoot. By doing the Dynamic Launch Event (DLE) the system, meaning the CPU, has effectively been reset. The CPU/Dynamic Configuration Environment (DCE) is expecting to be provided a kernel to measures, an entrypoint within that kernel to jump to, and that kernel understands the reset state of the system. As agreed, the callback approach is the most satisfactory approach to allow the efi-stub to do its private protocol. Once the flow has switched to a dynamic launch, the system is now starting the kernel via a dynamic launch sequence. The dynamic launch entrypoint, sl-stub, is and will be used as the entrypoint regardless of the firmware, UEFI/coreboot/oreboot/slimboot/etc., or CPU vendor, Intel/AMD, in use. Once efi-stub finishes and invokes the callback, its job is complete and the new dl-handler along with sl-stub from the current patch set will handle the system and security setup needed before entering into the kernel proper. To help provide clarity, consider the following flows for comparison, Normal/existing efi-stub: EFI -> efi-stub -> head_64.S Proposed secure launch: EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S Effectively, all this is doing is after efi-stub is done, instead of jumping into head_64.S, it will call the dynamic launch handler to do the dynamic launch, let sl_stub bring the system back into an expected state, and then enter head_64.S just as efi-stub would have done. > If we add another entry point into the kernel proper for the Secure > Launch Entry component to use, we are again exposing an internal ABI > in a way that limits our future ability to make changes to the EFI <-> > kernel handover. I am not sure how you make that jump, but as I stated above, when incorporating dynamic launch it is no longer a straight pass from EFI to kernel proper. The sl-stub is there to provide a common entry point from the CPU as the result of a dynamic launch, regardless of firmware or vendor. Once sl-stub is done with its start-of-day setup, it will jump to the same location efi-stub would have jumped. This means, efi-stub does everything it always has and is free to change what it does. The only addition is that it will now enable a call-out to allow secure launch to do what it needs to do, and then execution returns back to head_64.S. To be concise, it specifically returns where efi-stub would have jumped to without removing or circumventing anything from the existing flow. It should also be noted that sl-stub will not be looking to reconfigure the kernel. It will use the kernel as it was set up by efi-stub. The only job of sl-stub is to make the world right, measure what efi-stub provided for measurement, and then enter the kernel proper. The design of the SLRT structure below is specifically not to bind to anything from the efi-stub ABI/API. The only information needed to take the measurements is the location of any config items, their size, and an identifier for each item. The efi-stub is free to add to and/or remove from the list of items, along with changing where it is stored, or even change the format of existing items. The one recommendation, not requirement, is that the identifiers should not freely be changed. While it has no impact on sl-stub, it will likely be unpopular with anyone attempting to keep a manifest of valid efi-stub config items for attestation verification. It will result in having to maintain a volatile two-parameter map of (kernel version, identifier) to config item, at a minimum. <snip/> >> First, a short review of what the Secure Launch Resource Table is and >> its purpose. The SLRT is to provide a platform and kernel agnostic >> configuration table of the meta-data pertinent to the Secure Launch >> entry points for the variety of kernels the TrenchBoot project will be >> seeking to support. The specification for the table is in progress, but >> the consensus is that it will consist of a header structure followed by >> a packed series of TLV records. The specification will describe the >> various types of records, but the ones of interests in this discussion >> are those that efi-stub would use to record how it configured the >> environment. >> >> The initially proposed TLV record, see below, for EFI configuration >> information was devised around allowing an EFI bootloader to save >> multiple config events under a single TLV record. In discussions on the >> specification thus far, there are questions if it would be better to >> have a TLV record for each config event or the proposed multiple events >> per TLV record. It is worth noting that an assumption is being made in >> the proposed record. The assumption is that a config event will either >> be setting a configuration value between 1 and 8 bytes, or it will be a >> data blob for which the address and size will be recorded. The question >> is whether that covers all actions the efi-stub does or expects that it >> will have to do in the near future. >> >> struct slrt_entry_efi_config_event { >> struct slrt_entry_hdr hdr; >> uint32_t identifier; /* EFI bootloader ID */ >> uint16_t reserved; >> uint16_t nr_entries; /* Num cfg records */ >> struct efi_cfg_value values[0]; /* Array of cfg values */ >> }; >> >> struct efi_cfg_value { >> uint64_t data; /* cfg data (address or value) */ >> uint32_t size; /* data size if data is an addr */ >> uint32_t flags; /* 1L<0 IS_ADDR: data is an addr */ >> char evt_info[8]; /* event info str for TPM event log */ >> }; >> >> Hopefully the general approach here is agreeable, as IMHO it does >> provide a fairly elegant approach to resolving the issues at hand. >> Details can always be negotiated to address various implementation >> concerns. Provided this is acceptable, then everyone here is welcome to >> provide input on the Secure Launch specification, link forthcoming. >> > > Given that this is EFI, I would expect all these implementation > details to be exposed via a protocol that the stub can invoke, in a > way that will likely be similar (or the same?) as the TCG protocol > used for recording PCR measurements. The intent here was not to devise a new EFI protocol. This table is an agnostic structure that all TrenchBoot Secure Launch implementations will be using for all firmware environments, and will provide platform relevant sections like the EFI section outlined above. The table will inform the dl-handler so that it may take appropriate setup actions for the dynamic launch. The larger user of the table will be the sl-stub, which it will use to have an understanding of the world it inherited from whomever invoked the dynamic launch. > So could you elaborate on the types of actions? Is this simply things > like the command line, initrd contents, initrd load address, kernel > load address etc etc? There isn't generally that much going on in the > stub beyond that. Actually, those items are already in well-defined locations for which we are already taking measurements. The items of concern are the items being passed or configured that are stored outside the boot params. For instance, ROM files passed to the kernel or EFI environment variables that efi-stub may have set and/or will be used by the kernel. V/r, Daniel P. Smith ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-05 18:35 ` Daniel P. Smith @ 2022-07-06 0:03 ` Brendan Trotter 2022-07-06 0:12 ` Matthew Garrett 2022-07-07 9:46 ` Daniel P. Smith 2022-08-05 12:53 ` Ard Biesheuvel 1 sibling, 2 replies; 32+ messages in thread From: Brendan Trotter @ 2022-07-06 0:03 UTC (permalink / raw) To: The development of GNU GRUB Cc: Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris Hi, On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith <dpsmith@apertussolutions.com> wrote: > On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, > To help provide clarity, consider the following flows for comparison, > > Normal/existing efi-stub: > EFI -> efi-stub -> head_64.S > > Proposed secure launch: > EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S For more clarity; the entire point is to ensure that the kernel only has to trust itself and the CPU/TPM hardware (and does not have to trust a potentially malicious boot loader)..Any attempt to avoid a one-off solution for Linux is an attempt to weaken security. The only correct approach is "efi-stub -> head_64.S -> kernel's own secure init"; where (on UEFI systems) neither GRUB nor Trenchboot has a valid reason to exist and should never be installed. Cheers, Brendan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-06 0:03 ` Brendan Trotter @ 2022-07-06 0:12 ` Matthew Garrett 2022-07-07 9:46 ` Daniel P. Smith 1 sibling, 0 replies; 32+ messages in thread From: Matthew Garrett @ 2022-07-06 0:12 UTC (permalink / raw) To: Brendan Trotter Cc: The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On Wed, Jul 06, 2022 at 09:33:23AM +0930, Brendan Trotter wrote: > The only correct approach is "efi-stub -> head_64.S -> kernel's own > secure init"; where (on UEFI systems) neither GRUB nor Trenchboot has > a valid reason to exist and should never be installed. Surely the entire point of DRTM is that we *don't* have to trust the bootloader? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-06 0:03 ` Brendan Trotter 2022-07-06 0:12 ` Matthew Garrett @ 2022-07-07 9:46 ` Daniel P. Smith 2022-07-08 3:36 ` Brendan Trotter 1 sibling, 1 reply; 32+ messages in thread From: Daniel P. Smith @ 2022-07-07 9:46 UTC (permalink / raw) To: The development of GNU GRUB, Brendan Trotter Cc: Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On 7/5/22 20:03, Brendan Trotter wrote: > Hi, Greetings! Not sure why I got dropped from distro, but no worries. > On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith > <dpsmith@apertussolutions.com> wrote: >> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, >> To help provide clarity, consider the following flows for comparison, >> >> Normal/existing efi-stub: >> EFI -> efi-stub -> head_64.S >> >> Proposed secure launch: >> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S > > For more clarity; the entire point is to ensure that the kernel only > has to trust itself and the CPU/TPM hardware (and does not have to > trust a potentially malicious boot loader)..Any attempt to avoid a > one-off solution for Linux is an attempt to weaken security. Please elaborate so I might understand how this entrypoint allows for the kernel to only trust itself and the CPU/TPM. > The only correct approach is "efi-stub -> head_64.S -> kernel's own > secure init"; where (on UEFI systems) neither GRUB nor Trenchboot has > a valid reason to exist and should never be installed. > > > Cheers, > > Brendan v/r, dps ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-07 9:46 ` Daniel P. Smith @ 2022-07-08 3:36 ` Brendan Trotter 2022-07-08 4:56 ` Matthew Garrett 2022-07-22 17:23 ` Daniel P. Smith 0 siblings, 2 replies; 32+ messages in thread From: Brendan Trotter @ 2022-07-08 3:36 UTC (permalink / raw) To: Daniel P. Smith Cc: The development of GNU GRUB, Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris Hi, On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith <dpsmith@apertussolutions.com> wrote: > On 7/5/22 20:03, Brendan Trotter wrote: > Greetings! > > Not sure why I got dropped from distro, but no worries. > > > On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith > > <dpsmith@apertussolutions.com> wrote: > >> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, > >> To help provide clarity, consider the following flows for comparison, > >> > >> Normal/existing efi-stub: > >> EFI -> efi-stub -> head_64.S > >> > >> Proposed secure launch: > >> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S > > > > For more clarity; the entire point is to ensure that the kernel only > > has to trust itself and the CPU/TPM hardware (and does not have to > > trust a potentially malicious boot loader)..Any attempt to avoid a > > one-off solution for Linux is an attempt to weaken security. > > Please elaborate so I might understand how this entrypoint allows for > the kernel to only trust itself and the CPU/TPM. Is this a serious request? Kernel is started (via. firmware using the kernel's efi-stub, or via. "kexec()", or..); and regardless of how the kernel was started the kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or Intel's TXT, followed by measuring the remainder of itself and anything passed from firmware like APCI tables) without relying on a call-back provided by "untrusted by kernel" third-parties that don't exist in most cases. The dynamic root of trust that kernel creates depends on the kernel, CPU, TPM, etc (and excludes untrusted and unnecessary third parties).. The only potential benefit that the callback solution provides is that it, in theory, it could reduce duplication of work for other operating systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same callback instead of doing it themselves); but previous discussions (talk of formalising the contract between the boot stub and the Linux kernel) suggest that you aren't interested in any other OS. This leaves me wondering what your true motivation is. Are you trying to benefit GRUB/Trenchboot (at the expense of security, end-user convenience, distro installer hassle, etc); or trying to manufacture scope for future man-in-the middle attacks (by promoting a solution that requires something between firmware and kernel)? - Brendan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-08 3:36 ` Brendan Trotter @ 2022-07-08 4:56 ` Matthew Garrett 2022-07-22 17:23 ` Daniel P. Smith 1 sibling, 0 replies; 32+ messages in thread From: Matthew Garrett @ 2022-07-08 4:56 UTC (permalink / raw) To: Brendan Trotter Cc: Daniel P. Smith, The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On Fri, Jul 08, 2022 at 01:06:19PM +0930, Brendan Trotter wrote: > This leaves me wondering what your true motivation is. Are you trying > to benefit GRUB/Trenchboot (at the expense of security, end-user > convenience, distro installer hassle, etc); or trying to manufacture > scope for future man-in-the middle attacks (by promoting a solution > that requires something between firmware and kernel)? The described mechanism doesn't require trusting the code that's in the middle - if the state is perturbed by this code, the measurements will be different, and the system will be untrusted. I agree that this implementation is more complicated than just leaving it all up to the kernel, but I'm having a *lot* of trouble seeing how this has any impact on its security. Jumping immediately to impugning the motivation of the people involved is entirely inappropriate. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-08 3:36 ` Brendan Trotter 2022-07-08 4:56 ` Matthew Garrett @ 2022-07-22 17:23 ` Daniel P. Smith 2022-07-23 5:15 ` Brendan Trotter 1 sibling, 1 reply; 32+ messages in thread From: Daniel P. Smith @ 2022-07-22 17:23 UTC (permalink / raw) To: Brendan Trotter Cc: The development of GNU GRUB, Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On 7/7/22 23:36, Brendan Trotter wrote: > Hi, > > On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith > <dpsmith@apertussolutions.com> wrote: >> On 7/5/22 20:03, Brendan Trotter wrote: >> Greetings! >> >> Not sure why I got dropped from distro, but no worries. >> >>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith >>> <dpsmith@apertussolutions.com> wrote: >>>> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, >>>> To help provide clarity, consider the following flows for comparison, >>>> >>>> Normal/existing efi-stub: >>>> EFI -> efi-stub -> head_64.S >>>> >>>> Proposed secure launch: >>>> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S >>> >>> For more clarity; the entire point is to ensure that the kernel only >>> has to trust itself and the CPU/TPM hardware (and does not have to >>> trust a potentially malicious boot loader)..Any attempt to avoid a >>> one-off solution for Linux is an attempt to weaken security. >> >> Please elaborate so I might understand how this entrypoint allows for >> the kernel to only trust itself and the CPU/TPM. > > Is this a serious request? Yes, it was serious because I found the statements to be terse and open to interpretation. Specifically, when I read it, it almost seemed that the position is that dynamic launch is not needed, and that the kernel could just establish its own RoT. > Kernel is started (via. firmware using the kernel's efi-stub, or via. > "kexec()", or..); and regardless of how the kernel was started the > kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or > Intel's TXT, followed by measuring the remainder of itself and > anything passed from firmware like APCI tables) without relying on a > call-back provided by "untrusted by kernel" third-parties that don't > exist in most cases. The dynamic root of trust that kernel creates > depends on the kernel, CPU, TPM, etc (and excludes untrusted and > unnecessary third parties).. This clarifies the previous statements and I would say, yes, this is one approach. Considering the challenges we have/are facing in getting a minimal post-launch handling (sl-stub) into the setup kernel, I would be hard-pressed to believe adding all the pre-launch handling would be found to be acceptable. If the intent is to have it completely self-contained, this would require, 1) the introduction of a TPM driver into the setup kernel, a hole I would rather not go down again 2) potentially the ability to load files from disk if it is not acceptable for the bootloader to load the DCE (ACM/SLB) 3) miscellaneous system evaluations, memory table, machine check, etc. The only thing that is gained from such an approach is to make dynamic launch for Linux be self-contained in the kernel. It does not reduce the TCB because the whole design of the dynamic launch is to provide a controlled process that establishes a new trust chain/TCB that is started from an untrusted state. Specifically, dynamic launch starts with the CPU being provided all the material for the process by untrusted code that is currently in control at the time the launch is initiated. > The only potential benefit that the callback solution provides is that > it, in theory, it could reduce duplication of work for other operating > systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same > callback instead of doing it themselves); but previous discussions > (talk of formalising the contract between the boot stub and the Linux > kernel) suggest that you aren't interested in any other OS. With all due respect, but this is where I would have to disagree. There is substantial benefit, 1) a single code base that needs to be reviewed vs multiple OS specific versions 2) establishes an API that decouples pre- and post-launch 3) reduces the complexity required to enable adoption by an OS 4) zero reduction in the security properties of the architecture > This leaves me wondering what your true motivation is. Are you trying > to benefit GRUB/Trenchboot (at the expense of security, end-user > convenience, distro installer hassle, etc); or trying to manufacture > scope for future man-in-the middle attacks (by promoting a solution > that requires something between firmware and kernel)? As a loyal member of the tinfoil hat brigade, I will always advocate for accept nothing and question everything. All I can ask is to evaluate the technical merit of the presentations [1][2][3] and the patch series [4]. If there is anything concerning with the theory or the implementation, then it should be raised so that it may be addressed. A means to do so is the "what if" game, as it is great to formulate a hypothesis. In this case, the "what if" postulated is the assumption that the approach is to allow a future MitM attack. Then the challenge is to examine the process, their underlying mechanism, and the security properties of those mechanisms to see if a MitM can be discerned. I will gladly engage with anyone that presents an analysis demonstrating an assumption I made/missed that opens the possibility for subversion of the launch integrity attempting to be built. [1] https://www.platformsecuritysummit.com/2018/speaker/smith/ [2] https://events19.linuxfoundation.org/events/linux-security-summit-north-america-2019/program/schedule/ [3] https://lpc.events/event/7/contributions/739/ [4] https://lkml.org/lkml/2022/2/18/699 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-22 17:23 ` Daniel P. Smith @ 2022-07-23 5:15 ` Brendan Trotter 2022-08-09 10:53 ` Daniel P. Smith 0 siblings, 1 reply; 32+ messages in thread From: Brendan Trotter @ 2022-07-23 5:15 UTC (permalink / raw) To: Daniel P. Smith Cc: The development of GNU GRUB, Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris Hi, On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith <dpsmith@apertussolutions.com> wrote: > On 7/7/22 23:36, Brendan Trotter wrote: > > On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith > > <dpsmith@apertussolutions.com> wrote: > >> On 7/5/22 20:03, Brendan Trotter wrote: > >>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith > >>> <dpsmith@apertussolutions.com> wrote: > >>>> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, > >>>> To help provide clarity, consider the following flows for comparison, > >>>> > >>>> Normal/existing efi-stub: > >>>> EFI -> efi-stub -> head_64.S > >>>> > >>>> Proposed secure launch: > >>>> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S > >>> > >>> For more clarity; the entire point is to ensure that the kernel only > >>> has to trust itself and the CPU/TPM hardware (and does not have to > >>> trust a potentially malicious boot loader)..Any attempt to avoid a > >>> one-off solution for Linux is an attempt to weaken security. > >> > >> Please elaborate so I might understand how this entrypoint allows for > >> the kernel to only trust itself and the CPU/TPM. > > > > Is this a serious request? > > Yes, it was serious because I found the statements to be terse and open > to interpretation. Specifically, when I read it, it almost seemed that > the position is that dynamic launch is not needed, and that the kernel > could just establish its own RoT. > > > Kernel is started (via. firmware using the kernel's efi-stub, or via. > > "kexec()", or..); and regardless of how the kernel was started the > > kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or > > Intel's TXT, followed by measuring the remainder of itself and > > anything passed from firmware like APCI tables) without relying on a > > call-back provided by "untrusted by kernel" third-parties that don't > > exist in most cases. The dynamic root of trust that kernel creates > > depends on the kernel, CPU, TPM, etc (and excludes untrusted and > > unnecessary third parties).. > > This clarifies the previous statements and I would say, yes, this is one > approach. Considering the challenges we have/are facing in getting a > minimal post-launch handling (sl-stub) into the setup kernel, I would be > hard-pressed to believe adding all the pre-launch handling would be > found to be acceptable. If the intent is to have it completely > self-contained, this would require, > 1) the introduction of a TPM driver into the setup kernel, a hole I > would rather not go down again ..which is no more work than the introduction of a TPM driver into one boot loader (probably less so, as Linux already has TPM drivers that are used later), and significantly less work than introducing a TPM driver into many boot loaders. Note that to do this well (with some protection against malicious devices) you'd disable all PCI devices, then set up IOMMU as "allow the least possible", then establish a dynamic root of trust, then enable and allow individual devices only if/when their driver is started by kernel and not sooner. Without doing it like this there's less guarantee that the code/data being measured is the same as the code/data being executed/used (as a malicious device can modify anything before it's measured, restore the original extremely briefly while measurement is done, then modify anything after it's measured and before it's used). Also note that I mean "some protection" and not 100% protection (it's unsolvable unless firmware uses an "allow the least necessary by default" strategy) but "some protection" is better than none. In other words; it isn't necessarily just TPM driver alone that would need to be started "earlier" (ideally it's also IOMMU and PCI enumeration too). However, "earlier" is "earlier than the establishment of dynamic root of trust"; which can be achieved by moving the establishment of dynamic root of trust to a later stage (rather than bringing things like TPM driver to an earlier stage).. > 2) potentially the ability to load files from disk if it is not > acceptable for the bootloader to load the DCE (ACM/SLB) ..which is both unnecessary and ill-advised. > 3) miscellaneous system evaluations, memory table, machine check, etc. ..which is the same regardless of where it's done. > The only thing that is gained from such an approach is to make dynamic > launch for Linux be self-contained in the kernel. Making it self-contained in the kernel means: a) it actually works, for the most important use case (where UEFI firmware boots Linux's efi-stub directly) b) it actually works, for other use cases (booted via. "kexec()", booted from LILO, booted from ELILO, ...). c) It continues to work; even when you change/update/install/remove a boot manager (which would otherwise change the measurement and break anything that depended on the measurement). d) it's more portable (e.g. easier to port to ARM/Uboot, etc) e) It's more likely to actually be used by end-users (can just install a kernel like normal without extra pages of instructions on how to install and configure unnecessary bootware) f) It'll be peer reviewed by more people > It does not reduce the > TCB because the whole design of the dynamic launch is to provide a > controlled process that establishes a new trust chain/TCB that is > started from an untrusted state. Specifically, dynamic launch starts > with the CPU being provided all the material for the process by > untrusted code that is currently in control at the time the launch is > initiated. The whole design of dynamic launch is to establish a new trust chain that doesn't depend on an untrusted boot loader (or anything that came before it - firmware, etc). If the "dynamic root of trust" is established by boot loader then it partially suffers the same problems as a static root of trust. > > The only potential benefit that the callback solution provides is that > > it, in theory, it could reduce duplication of work for other operating > > systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same > > callback instead of doing it themselves); but previous discussions > > (talk of formalising the contract between the boot stub and the Linux > > kernel) suggest that you aren't interested in any other OS. > > With all due respect, but this is where I would have to disagree. There > is substantial benefit, > 1) a single code base that needs to be reviewed vs multiple OS > specific versions If you wanted to minimize code duplication you'd implement it as an open source library (with a non-restrictive licence like MIT) so that the code can be used by all the different boot loaders instead of duplicated by each different boot loader, in addition to being used by all the different operating systems/kernels. > 2) establishes an API that decouples pre- and post-launch ..by providing a call-back that kernel uses post-launch to call an API from pre-launch, that couples pre- and post-launch more than has ever been done before? > 3) reduces the complexity required to enable adoption by an OS There's only one OS that uses the Linux Boot Protocol. Any other OS (FreeBSD, Fuschia, Haiku, ...) has to radically change everything about how it boots before it can think about adopting your Linux specific solution. Is there even a proposal to add support to GRUB developers' own multi-boot specification (to "enable easy adoption" by Solaris and its forks)? Building it directly into the Linux kernel would make adoption by other operating systems easier, as they wouldn't need to change their boot code and most of them are used to porting code from Linux anway. > 4) zero reduction in the security properties of the architecture It's a huge reduction in the security properties. It allows a "just lie and measure nothing" boot loader to be (pre)installed,, tricking the kernel into thinking there's security when there is none. > > This leaves me wondering what your true motivation is. Are you trying > > to benefit GRUB/Trenchboot (at the expense of security, end-user > > convenience, distro installer hassle, etc); or trying to manufacture > > scope for future man-in-the middle attacks (by promoting a solution > > that requires something between firmware and kernel)? > > As a loyal member of the tinfoil hat brigade, I will always advocate for > accept nothing and question everything. All I can ask is to evaluate the > technical merit of the presentations [1][2][3] and the patch series [4]. > If there is anything concerning with the theory or the implementation, > then it should be raised so that it may be addressed. A means to do so > is the "what if" game, as it is great to formulate a hypothesis. In this > case, the "what if" postulated is the assumption that the approach is to > allow a future MitM attack. How quickly could a disgruntled system administrator (or someone selling computers with a Linux distro pre-installed, or anyone trying to circumvent a company's digital rights management scheme that happens to rely on DRTM for remote attestation, or...) break your security in a way that survives kernel updates? My estimate is that it'd take about 5 minutes to download the boot loader's open source code then 10 minutes to modify it. The only real safeguard against this is UEFI's Secure Boot, which doesn't work on old computers or most "non-8086" computers, doesn't work if an attacker can install their own secure boot keys, and doesn't work in most virtual machines. > Then the challenge is to examine the > process, their underlying mechanism, and the security properties of > those mechanisms to see if a MitM can be discerned. I will gladly engage > with anyone that presents an analysis demonstrating an assumption I > made/missed that opens the possibility for subversion of the launch > integrity attempting to be built. Surely it'd be easier for kernel to ignore the bootloader's "untrustworthy dynamic root of trust" (and establish its own "trustworthy dynamic root of trust") than it would be for kernel to detect a MiTM boot loader. - Brendan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-23 5:15 ` Brendan Trotter @ 2022-08-09 10:53 ` Daniel P. Smith 2022-08-10 9:07 ` Brendan Trotter 0 siblings, 1 reply; 32+ messages in thread From: Daniel P. Smith @ 2022-08-09 10:53 UTC (permalink / raw) To: Brendan Trotter Cc: The development of GNU GRUB, Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On 7/23/22 01:15, Brendan Trotter wrote: > Hi, Greetings, > On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith > <dpsmith@apertussolutions.com> wrote: >> On 7/7/22 23:36, Brendan Trotter wrote: >>> On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith >>> <dpsmith@apertussolutions.com> wrote: >>>> On 7/5/22 20:03, Brendan Trotter wrote: >>>>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith >>>>> <dpsmith@apertussolutions.com> wrote: >>>>>> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, >>>>>> To help provide clarity, consider the following flows for comparison, >>>>>> >>>>>> Normal/existing efi-stub: >>>>>> EFI -> efi-stub -> head_64.S >>>>>> >>>>>> Proposed secure launch: >>>>>> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S >>>>> >>>>> For more clarity; the entire point is to ensure that the kernel only >>>>> has to trust itself and the CPU/TPM hardware (and does not have to >>>>> trust a potentially malicious boot loader)..Any attempt to avoid a >>>>> one-off solution for Linux is an attempt to weaken security. >>>> >>>> Please elaborate so I might understand how this entrypoint allows for >>>> the kernel to only trust itself and the CPU/TPM. >>> >>> Is this a serious request? >> >> Yes, it was serious because I found the statements to be terse and open >> to interpretation. Specifically, when I read it, it almost seemed that >> the position is that dynamic launch is not needed, and that the kernel >> could just establish its own RoT. >> >>> Kernel is started (via. firmware using the kernel's efi-stub, or via. >>> "kexec()", or..); and regardless of how the kernel was started the >>> kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or >>> Intel's TXT, followed by measuring the remainder of itself and >>> anything passed from firmware like APCI tables) without relying on a >>> call-back provided by "untrusted by kernel" third-parties that don't >>> exist in most cases. The dynamic root of trust that kernel creates >>> depends on the kernel, CPU, TPM, etc (and excludes untrusted and >>> unnecessary third parties).. >> >> This clarifies the previous statements and I would say, yes, this is one >> approach. Considering the challenges we have/are facing in getting a >> minimal post-launch handling (sl-stub) into the setup kernel, I would be >> hard-pressed to believe adding all the pre-launch handling would be >> found to be acceptable. If the intent is to have it completely >> self-contained, this would require, >> 1) the introduction of a TPM driver into the setup kernel, a hole I >> would rather not go down again > > ..which is no more work than the introduction of a TPM driver into one > boot loader (probably less so, as Linux already has TPM drivers that > are used later), and significantly less work than introducing a TPM > driver into many boot loaders. Already been there and no it is not as straight forward as one may think. A minimal driver was attempted but rejected by the TPM maintainers with the requirement to reuse the existing driver code. So we would gladly welcome someone to come rewrite the TPM drive. Specifically to de-tangle the core TPM interface code away from all of its kernel proper dependencies so that it can be used by both the setup kernel and the kernel proper. > Note that to do this well (with some protection against malicious > devices) you'd disable all PCI devices, then set up IOMMU as "allow > the least possible", then establish a dynamic root of trust, then > enable and allow individual devices only if/when their driver is > started by kernel and not sooner. Without doing it like this there's > less guarantee that the code/data being measured is the same as the > code/data being executed/used (as a malicious device can modify > anything before it's measured, restore the original extremely briefly > while measurement is done, then modify anything after it's measured > and before it's used). Also note that I mean "some protection" and not > 100% protection (it's unsolvable unless firmware uses an "allow the > least necessary by default" strategy) but "some protection" is better > than none. > > In other words; it isn't necessarily just TPM driver alone that would > need to be started "earlier" (ideally it's also IOMMU and PCI > enumeration too). However, "earlier" is "earlier than the > establishment of dynamic root of trust"; which can be achieved by > moving the establishment of dynamic root of trust to a later stage > (rather than bringing things like TPM driver to an earlier stage).. With all due respect, the statement above demonstrates a clear lack of understanding how the hardware dynamic launch works. I have written a summary[1], with links to details, of how the process works. It is highly recommended this is read, as well as the referenced sections in Intel's SDM and AMD's APM. >> 2) potentially the ability to load files from disk if it is not >> acceptable for the bootloader to load the DCE (ACM/SLB) > > ..which is both unnecessary and ill-advised. See [1] >> 3) miscellaneous system evaluations, memory table, machine check, etc. > > ..which is the same regardless of where it's done. > >> The only thing that is gained from such an approach is to make dynamic >> launch for Linux be self-contained in the kernel. > > Making it self-contained in the kernel means: > > a) it actually works, for the most important use case (where UEFI > firmware boots Linux's efi-stub directly) > > b) it actually works, for other use cases (booted via. "kexec()", > booted from LILO, booted from ELILO, ...). > > c) It continues to work; even when you change/update/install/remove a > boot manager (which would otherwise change the measurement and break > anything that depended on the measurement). > > d) it's more portable (e.g. easier to port to ARM/Uboot, etc) > > e) It's more likely to actually be used by end-users (can just install > a kernel like normal without extra pages of instructions on how to > install and configure unnecessary bootware) > > f) It'll be peer reviewed by more people The hook approach does all of this. >> It does not reduce the >> TCB because the whole design of the dynamic launch is to provide a >> controlled process that establishes a new trust chain/TCB that is >> started from an untrusted state. Specifically, dynamic launch starts >> with the CPU being provided all the material for the process by >> untrusted code that is currently in control at the time the launch is >> initiated. > > The whole design of dynamic launch is to establish a new trust chain > that doesn't depend on an untrusted boot loader (or anything that came > before it - firmware, etc). If the "dynamic root of trust" is > established by boot loader then it partially suffers the same problems > as a static root of trust. See [1] >>> The only potential benefit that the callback solution provides is that >>> it, in theory, it could reduce duplication of work for other operating >>> systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same >>> callback instead of doing it themselves); but previous discussions >>> (talk of formalising the contract between the boot stub and the Linux >>> kernel) suggest that you aren't interested in any other OS. >> >> With all due respect, but this is where I would have to disagree. There >> is substantial benefit, >> 1) a single code base that needs to be reviewed vs multiple OS >> specific versions > > If you wanted to minimize code duplication you'd implement it as an > open source library (with a non-restrictive licence like MIT) so that > the code can be used by all the different boot loaders instead of > duplicated by each different boot loader, in addition to being used by > all the different operating systems/kernels. I completely agree and my intent is to get there eventually. >> 2) establishes an API that decouples pre- and post-launch > > ..by providing a call-back that kernel uses post-launch to call an API > from pre-launch, that couples pre- and post-launch more than has ever > been done before? That is not what is being proposed. >> 3) reduces the complexity required to enable adoption by an OS > > There's only one OS that uses the Linux Boot Protocol. Any other OS > (FreeBSD, Fuschia, Haiku, ...) has to radically change everything > about how it boots before it can think about adopting your Linux > specific solution. Is there even a proposal to add support to GRUB > developers' own multi-boot specification (to "enable easy adoption" by > Solaris and its forks)? > > Building it directly into the Linux kernel would make adoption by > other operating systems easier, as they wouldn't need to change their > boot code and most of them are used to porting code from Linux anway. Nothing in this proposal binds it to the Linux Boot Protocol. >> 4) zero reduction in the security properties of the architecture > > It's a huge reduction in the security properties. It allows a "just > lie and measure nothing" boot loader to be (pre)installed,, tricking > the kernel into thinking there's security when there is none. See [1]. >>> This leaves me wondering what your true motivation is. Are you trying >>> to benefit GRUB/Trenchboot (at the expense of security, end-user >>> convenience, distro installer hassle, etc); or trying to manufacture >>> scope for future man-in-the middle attacks (by promoting a solution >>> that requires something between firmware and kernel)? >> >> As a loyal member of the tinfoil hat brigade, I will always advocate for >> accept nothing and question everything. All I can ask is to evaluate the >> technical merit of the presentations [1][2][3] and the patch series [4]. >> If there is anything concerning with the theory or the implementation, >> then it should be raised so that it may be addressed. A means to do so >> is the "what if" game, as it is great to formulate a hypothesis. In this >> case, the "what if" postulated is the assumption that the approach is to >> allow a future MitM attack. > > How quickly could a disgruntled system administrator (or someone > selling computers with a Linux distro pre-installed, or anyone trying > to circumvent a company's digital rights management scheme that > happens to rely on DRTM for remote attestation, or...) break your > security in a way that survives kernel updates? > > My estimate is that it'd take about 5 minutes to download the boot > loader's open source code then 10 minutes to modify it. > > The only real safeguard against this is UEFI's Secure Boot, which > doesn't work on old computers or most "non-8086" computers, doesn't > work if an attacker can install their own secure boot keys, and > doesn't work in most virtual machines. See [1]. >> Then the challenge is to examine the >> process, their underlying mechanism, and the security properties of >> those mechanisms to see if a MitM can be discerned. I will gladly engage >> with anyone that presents an analysis demonstrating an assumption I >> made/missed that opens the possibility for subversion of the launch >> integrity attempting to be built. > > Surely it'd be easier for kernel to ignore the bootloader's > "untrustworthy dynamic root of trust" (and establish its own > "trustworthy dynamic root of trust") than it would be for kernel to > detect a MiTM boot loader. See [1]. > - Brendan [1] https://trenchboot.org/documentation/Late_Launch_Overview/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-09 10:53 ` Daniel P. Smith @ 2022-08-10 9:07 ` Brendan Trotter 2022-08-10 17:46 ` Matthew Garrett 0 siblings, 1 reply; 32+ messages in thread From: Brendan Trotter @ 2022-08-10 9:07 UTC (permalink / raw) To: The development of GNU GRUB Cc: Ard Biesheuvel, Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris Hi, On Tue, Aug 9, 2022 at 8:25 PM Daniel P. Smith <dpsmith@apertussolutions.com> wrote: > On 7/23/22 01:15, Brendan Trotter wrote: > > On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith > > <dpsmith@apertussolutions.com> wrote: > >> On 7/7/22 23:36, Brendan Trotter wrote: > >>> On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith > >>> <dpsmith@apertussolutions.com> wrote: > >>>> On 7/5/22 20:03, Brendan Trotter wrote: > >>>>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith > >>>>> <dpsmith@apertussolutions.com> wrote: > >>>>>> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59, > >>>>>> To help provide clarity, consider the following flows for comparison, > >>>>>> > >>>>>> Normal/existing efi-stub: > >>>>>> EFI -> efi-stub -> head_64.S > >>>>>> > >>>>>> Proposed secure launch: > >>>>>> EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S > >>>>> > >>>>> For more clarity; the entire point is to ensure that the kernel only > >>>>> has to trust itself and the CPU/TPM hardware (and does not have to > >>>>> trust a potentially malicious boot loader)..Any attempt to avoid a > >>>>> one-off solution for Linux is an attempt to weaken security. > >>>> > >>>> Please elaborate so I might understand how this entrypoint allows for > >>>> the kernel to only trust itself and the CPU/TPM. > >>> > >>> Is this a serious request? > >> > >> Yes, it was serious because I found the statements to be terse and open > >> to interpretation. Specifically, when I read it, it almost seemed that > >> the position is that dynamic launch is not needed, and that the kernel > >> could just establish its own RoT. > >> > >>> Kernel is started (via. firmware using the kernel's efi-stub, or via. > >>> "kexec()", or..); and regardless of how the kernel was started the > >>> kernel establishes its own dynamic root of trust.(e.g. AMD"s SKINIT or > >>> Intel's TXT, followed by measuring the remainder of itself and > >>> anything passed from firmware like APCI tables) without relying on a > >>> call-back provided by "untrusted by kernel" third-parties that don't > >>> exist in most cases. The dynamic root of trust that kernel creates > >>> depends on the kernel, CPU, TPM, etc (and excludes untrusted and > >>> unnecessary third parties).. > >> > >> This clarifies the previous statements and I would say, yes, this is one > >> approach. Considering the challenges we have/are facing in getting a > >> minimal post-launch handling (sl-stub) into the setup kernel, I would be > >> hard-pressed to believe adding all the pre-launch handling would be > >> found to be acceptable. If the intent is to have it completely > >> self-contained, this would require, > >> 1) the introduction of a TPM driver into the setup kernel, a hole I > >> would rather not go down again > > > > ..which is no more work than the introduction of a TPM driver into one > > boot loader (probably less so, as Linux already has TPM drivers that > > are used later), and significantly less work than introducing a TPM > > driver into many boot loaders. > > Already been there and no it is not as straight forward as one may > think. A minimal driver was attempted but rejected by the TPM > maintainers with the requirement to reuse the existing driver code. So > we would gladly welcome someone to come rewrite the TPM drive. > Specifically to de-tangle the core TPM interface code away from all of > its kernel proper dependencies so that it can be used by both the setup > kernel and the kernel proper. > > > Note that to do this well (with some protection against malicious > > devices) you'd disable all PCI devices, then set up IOMMU as "allow > > the least possible", then establish a dynamic root of trust, then > > enable and allow individual devices only if/when their driver is > > started by kernel and not sooner. Without doing it like this there's > > less guarantee that the code/data being measured is the same as the > > code/data being executed/used (as a malicious device can modify > > anything before it's measured, restore the original extremely briefly > > while measurement is done, then modify anything after it's measured > > and before it's used). Also note that I mean "some protection" and not > > 100% protection (it's unsolvable unless firmware uses an "allow the > > least necessary by default" strategy) but "some protection" is better > > than none. > > > > In other words; it isn't necessarily just TPM driver alone that would > > need to be started "earlier" (ideally it's also IOMMU and PCI > > enumeration too). However, "earlier" is "earlier than the > > establishment of dynamic root of trust"; which can be achieved by > > moving the establishment of dynamic root of trust to a later stage > > (rather than bringing things like TPM driver to an earlier stage).. > > With all due respect, the statement above demonstrates a clear lack of > understanding how the hardware dynamic launch works. I have written a > summary[1], with links to details, of how the process works. It is > highly recommended this is read, as well as the referenced sections in > Intel's SDM and AMD's APM. > > >> 2) potentially the ability to load files from disk if it is not > >> acceptable for the bootloader to load the DCE (ACM/SLB) > > > > ..which is both unnecessary and ill-advised. > > See [1] Yes? If you're referring to the "authenticated code module" (as part of senter's internal procedure) it's part of hardware/firmware and beyond the scope of software/boot loader/kernel. > >> 3) miscellaneous system evaluations, memory table, machine check, etc. > > > > ..which is the same regardless of where it's done. > > > >> The only thing that is gained from such an approach is to make dynamic > >> launch for Linux be self-contained in the kernel. > > > > Making it self-contained in the kernel means: > > > > a) it actually works, for the most important use case (where UEFI > > firmware boots Linux's efi-stub directly) > > > > b) it actually works, for other use cases (booted via. "kexec()", > > booted from LILO, booted from ELILO, ...). > > > > c) It continues to work; even when you change/update/install/remove a > > boot manager (which would otherwise change the measurement and break > > anything that depended on the measurement). > > > > d) it's more portable (e.g. easier to port to ARM/Uboot, etc) > > > > e) It's more likely to actually be used by end-users (can just install > > a kernel like normal without extra pages of instructions on how to > > install and configure unnecessary bootware) > > > > f) It'll be peer reviewed by more people > > The hook approach does all of this. > > >> It does not reduce the > >> TCB because the whole design of the dynamic launch is to provide a > >> controlled process that establishes a new trust chain/TCB that is > >> started from an untrusted state. Specifically, dynamic launch starts > >> with the CPU being provided all the material for the process by > >> untrusted code that is currently in control at the time the launch is > >> initiated. > > > > The whole design of dynamic launch is to establish a new trust chain > > that doesn't depend on an untrusted boot loader (or anything that came > > before it - firmware, etc). If the "dynamic root of trust" is > > established by boot loader then it partially suffers the same problems > > as a static root of trust. > > See [1] > > >>> The only potential benefit that the callback solution provides is that > >>> it, in theory, it could reduce duplication of work for other operating > >>> systems (FreeBSD, Solaris, Haiku, Fuchsia, .. could use the same > >>> callback instead of doing it themselves); but previous discussions > >>> (talk of formalising the contract between the boot stub and the Linux > >>> kernel) suggest that you aren't interested in any other OS. > >> > >> With all due respect, but this is where I would have to disagree. There > >> is substantial benefit, > >> 1) a single code base that needs to be reviewed vs multiple OS > >> specific versions > > > > If you wanted to minimize code duplication you'd implement it as an > > open source library (with a non-restrictive licence like MIT) so that > > the code can be used by all the different boot loaders instead of > > duplicated by each different boot loader, in addition to being used by > > all the different operating systems/kernels. > > I completely agree and my intent is to get there eventually. > > >> 2) establishes an API that decouples pre- and post-launch > > > > ..by providing a call-back that kernel uses post-launch to call an API > > from pre-launch, that couples pre- and post-launch more than has ever > > been done before? > > That is not what is being proposed. Maybe I'm confused. I thought the proposal was that unnecessary and untrusted code (Trenchboot) is inserted into "pre kernel launch" (between UEFI firmware and Linux's efi-stub), and then (during "post kernel launch") kernel calls a callback provided by "pre kernel launch" (Trenchboot); thereby coupling pre-launch (Trenchboot) and post-launch (Linux kernel) more than has ever be done before. I also assumed that if the 1st kernel runs for 6 months and then starts a 2nd kernel via. "kexec()" ; then the 2nd kernel would call the callback provided by "pre 1st kernel launch from 6 months ago". > >> 3) reduces the complexity required to enable adoption by an OS > > > > There's only one OS that uses the Linux Boot Protocol. Any other OS > > (FreeBSD, Fuschia, Haiku, ...) has to radically change everything > > about how it boots before it can think about adopting your Linux > > specific solution. Is there even a proposal to add support to GRUB > > developers' own multi-boot specification (to "enable easy adoption" by > > Solaris and its forks)? > > > > Building it directly into the Linux kernel would make adoption by > > other operating systems easier, as they wouldn't need to change their > > boot code and most of them are used to porting code from Linux anway. > > Nothing in this proposal binds it to the Linux Boot Protocol. > > >> 4) zero reduction in the security properties of the architecture > > > > It's a huge reduction in the security properties. It allows a "just > > lie and measure nothing" boot loader to be (pre)installed,, tricking > > the kernel into thinking there's security when there is none. > > See [1]. [1] doesn't provide any useful information. How does a kernel know that the callback provided by boot loader actually measures what it's supposed to measure, or even does anything at all? > >>> This leaves me wondering what your true motivation is. Are you trying > >>> to benefit GRUB/Trenchboot (at the expense of security, end-user > >>> convenience, distro installer hassle, etc); or trying to manufacture > >>> scope for future man-in-the middle attacks (by promoting a solution > >>> that requires something between firmware and kernel)? > >> > >> As a loyal member of the tinfoil hat brigade, I will always advocate for > >> accept nothing and question everything. All I can ask is to evaluate the > >> technical merit of the presentations [1][2][3] and the patch series [4]. > >> If there is anything concerning with the theory or the implementation, > >> then it should be raised so that it may be addressed. A means to do so > >> is the "what if" game, as it is great to formulate a hypothesis. In this > >> case, the "what if" postulated is the assumption that the approach is to > >> allow a future MitM attack. > > > > How quickly could a disgruntled system administrator (or someone > > selling computers with a Linux distro pre-installed, or anyone trying > > to circumvent a company's digital rights management scheme that > > happens to rely on DRTM for remote attestation, or...) break your > > security in a way that survives kernel updates? > > > > My estimate is that it'd take about 5 minutes to download the boot > > loader's open source code then 10 minutes to modify it. > > > > The only real safeguard against this is UEFI's Secure Boot, which > > doesn't work on old computers or most "non-8086" computers, doesn't > > work if an attacker can install their own secure boot keys, and > > doesn't work in most virtual machines. > > See [1]. [1] doesn't provide any useful information. Dynamic root of trust is only useful for detecting if a measurement changed; so if the measurement was always nonsense from the beginning and never changes it becomes worse than nothing. > >> Then the challenge is to examine the > >> process, their underlying mechanism, and the security properties of > >> those mechanisms to see if a MitM can be discerned. I will gladly engage > >> with anyone that presents an analysis demonstrating an assumption I > >> made/missed that opens the possibility for subversion of the launch > >> integrity attempting to be built. > > > > Surely it'd be easier for kernel to ignore the bootloader's > > "untrustworthy dynamic root of trust" (and establish its own > > "trustworthy dynamic root of trust") than it would be for kernel to > > detect a MiTM boot loader. > > See [1]. [1] doesn't provide any useful information. Senter and skinit don't provide a method for kernel to detect that (e.g.) a MiTM boot loader has always measured a forgery and has changed unmeasured code in a different way every time you boot. - Brendan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-10 9:07 ` Brendan Trotter @ 2022-08-10 17:46 ` Matthew Garrett 2022-08-11 9:55 ` Brendan Trotter 0 siblings, 1 reply; 32+ messages in thread From: Matthew Garrett @ 2022-08-10 17:46 UTC (permalink / raw) To: Brendan Trotter Cc: The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote: > [1] doesn't provide any useful information. How does a kernel know > that the callback provided by boot loader actually measures what it's > supposed to measure, or even does anything at all? The kernel has no way to know this - *any* code you've run before performing a measurement could tamper with the kernel such that it believes it's fine. This is just as true in DRTM as it is in SRTM. But you know what the expected measurements should be, so you're able to either seal secrets to those PCR values or rely on remote attestation. > [1] doesn't provide any useful information. Senter and skinit don't > provide a method for kernel to detect that (e.g.) a MiTM boot loader > has always measured a forgery and has changed unmeasured code in a > different way every time you boot. Measurements are not opaque objects. If you're not able to reconstruct the expected measurement then you're doing it wrong. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-10 17:46 ` Matthew Garrett @ 2022-08-11 9:55 ` Brendan Trotter 2022-08-11 11:34 ` Daniel Kiper 2022-08-11 18:25 ` Matthew Garrett 0 siblings, 2 replies; 32+ messages in thread From: Brendan Trotter @ 2022-08-11 9:55 UTC (permalink / raw) To: Matthew Garrett Cc: The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris Hi, On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote: > > > [1] doesn't provide any useful information. How does a kernel know > > that the callback provided by boot loader actually measures what it's > > supposed to measure, or even does anything at all? > > The kernel has no way to know this - *any* code you've run before > performing a measurement could tamper with the kernel such that it > believes it's fine. This is just as true in DRTM as it is in SRTM. But > you know what the expected measurements should be, so you're able to > either seal secrets to those PCR values or rely on remote attestation. In this scenario the kernel has no idea what the measurement should be, it only knows the measurement that a potentially malicious boot loader felt like giving the kernel previously (e.g. when the kernel was installed). > > [1] doesn't provide any useful information. Senter and skinit don't > > provide a method for kernel to detect that (e.g.) a MiTM boot loader > > has always measured a forgery and has changed unmeasured code in a > > different way every time you boot. > > Measurements are not opaque objects. If you're not able to reconstruct > the expected measurement then you're doing it wrong. OK; so to detect if boot loader has always given kernel a bad/forged measurement; the kernel repeats all of the steps involved in creating the measurement itself exactly the same as the boot loader should have (but might not have) so that kernel can compare a "known good/trustworthy" measurement with the useless measurement that the boot loader created for no sane reason whatsoever? - Brendan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-11 9:55 ` Brendan Trotter @ 2022-08-11 11:34 ` Daniel Kiper 2022-08-11 18:25 ` Matthew Garrett 1 sibling, 0 replies; 32+ messages in thread From: Daniel Kiper @ 2022-08-11 11:34 UTC (permalink / raw) To: Brendan Trotter Cc: Matthew Garrett, The development of GNU GRUB, Ard Biesheuvel, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris, dpsmith On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > Hi, > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote: > > > > > [1] doesn't provide any useful information. How does a kernel know > > > that the callback provided by boot loader actually measures what it's > > > supposed to measure, or even does anything at all? > > > > The kernel has no way to know this - *any* code you've run before > > performing a measurement could tamper with the kernel such that it > > believes it's fine. This is just as true in DRTM as it is in SRTM. But > > you know what the expected measurements should be, so you're able to > > either seal secrets to those PCR values or rely on remote attestation. > > In this scenario the kernel has no idea what the measurement should > be, it only knows the measurement that a potentially malicious boot > loader felt like giving the kernel previously (e.g. when the kernel > was installed). > > > > [1] doesn't provide any useful information. Senter and skinit don't > > > provide a method for kernel to detect that (e.g.) a MiTM boot loader > > > has always measured a forgery and has changed unmeasured code in a > > > different way every time you boot. > > > > Measurements are not opaque objects. If you're not able to reconstruct > > the expected measurement then you're doing it wrong. > > OK; so to detect if boot loader has always given kernel a bad/forged > measurement; the kernel repeats all of the steps involved in creating > the measurement itself exactly the same as the boot loader should have > (but might not have) so that kernel can compare a "known > good/trustworthy" measurement with the useless measurement that the > boot loader created for no sane reason whatsoever? Could you tell us where exactly boot loader creates measurements for the DRTM? Daniel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-11 9:55 ` Brendan Trotter 2022-08-11 11:34 ` Daniel Kiper @ 2022-08-11 18:25 ` Matthew Garrett 2022-08-12 3:22 ` Brendan Trotter 1 sibling, 1 reply; 32+ messages in thread From: Matthew Garrett @ 2022-08-11 18:25 UTC (permalink / raw) To: Brendan Trotter Cc: The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > Hi, > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > The kernel has no way to know this - *any* code you've run before > > performing a measurement could tamper with the kernel such that it > > believes it's fine. This is just as true in DRTM as it is in SRTM. But > > you know what the expected measurements should be, so you're able to > > either seal secrets to those PCR values or rely on remote attestation. > > In this scenario the kernel has no idea what the measurement should > be, it only knows the measurement that a potentially malicious boot > loader felt like giving the kernel previously (e.g. when the kernel > was installed). Even if the kernel has an idea of what the measurement should be, it has no way to verify that what it believes to be true is true - any malicious code could simply have modified the kernel to believe that anything it asks the TPM returns the "correct" answer. > > Measurements are not opaque objects. If you're not able to reconstruct > > the expected measurement then you're doing it wrong. > > OK; so to detect if boot loader has always given kernel a bad/forged > measurement; the kernel repeats all of the steps involved in creating > the measurement itself exactly the same as the boot loader should have > (but might not have) so that kernel can compare a "known > good/trustworthy" measurement with the useless measurement that the > boot loader created for no sane reason whatsoever? No, some external agent does. Code running on the local machine can never determine whether the machine is trustworthy. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-11 18:25 ` Matthew Garrett @ 2022-08-12 3:22 ` Brendan Trotter 2022-08-12 5:54 ` Matthew Garrett 0 siblings, 1 reply; 32+ messages in thread From: Brendan Trotter @ 2022-08-12 3:22 UTC (permalink / raw) To: Matthew Garrett Cc: The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris Hi, On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > The kernel has no way to know this - *any* code you've run before > > > performing a measurement could tamper with the kernel such that it > > > believes it's fine. This is just as true in DRTM as it is in SRTM. But > > > you know what the expected measurements should be, so you're able to > > > either seal secrets to those PCR values or rely on remote attestation. > > > > In this scenario the kernel has no idea what the measurement should > > be, it only knows the measurement that a potentially malicious boot > > loader felt like giving the kernel previously (e.g. when the kernel > > was installed). > > Even if the kernel has an idea of what the measurement should be, it has > no way to verify that what it believes to be true is true - any > malicious code could simply have modified the kernel to believe that > anything it asks the TPM returns the "correct" answer. Right. To achieve the best possible security; you'd need Secure Boot to ensure that the kernel itself wasn't modified, and then the kernel establishes a dynamic root of trust itself. Anything involving a boot loader (e.g. Secure Boot ensure's boot loader wasn't modified, then boot loader ensure's kernel wasn't modified, then ....) increases the attack surface for no benefit. > > > Measurements are not opaque objects. If you're not able to reconstruct > > > the expected measurement then you're doing it wrong. > > > > OK; so to detect if boot loader has always given kernel a bad/forged > > measurement; the kernel repeats all of the steps involved in creating > > the measurement itself exactly the same as the boot loader should have > > (but might not have) so that kernel can compare a "known > > good/trustworthy" measurement with the useless measurement that the > > boot loader created for no sane reason whatsoever? > > No, some external agent does. Code running on the local machine can > never determine whether the machine is trustworthy. This part of the conversation evolved from "there's no way for kernel to detect a MiTM boot loader (that provides a bad/forged measurement)". I'm not convinced an external agent can detect "bad/forged measurement" either. E.g. if a MiTM boot loader always provided a bad/forged measurement the external agent won't detect it (as the measurement always matches the expected measurement), and then if the MiTM boot loader is replaced by a good/honest boot loader the external agent will decide that the good/honest boot loader is malicious because its measurement doesn't match the expected bad/forged measurement. - Brendan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-08-12 3:22 ` Brendan Trotter @ 2022-08-12 5:54 ` Matthew Garrett 0 siblings, 0 replies; 32+ messages in thread From: Matthew Garrett @ 2022-08-12 5:54 UTC (permalink / raw) To: Brendan Trotter Cc: The development of GNU GRUB, Ard Biesheuvel, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, linux-kernel, James Morris On Fri, Aug 12, 2022 at 12:52:58PM +0930, Brendan Trotter wrote: > Hi, > > On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > > The kernel has no way to know this - *any* code you've run before > > > > performing a measurement could tamper with the kernel such that it > > > > believes it's fine. This is just as true in DRTM as it is in SRTM. But > > > > you know what the expected measurements should be, so you're able to > > > > either seal secrets to those PCR values or rely on remote attestation. > > > > > > In this scenario the kernel has no idea what the measurement should > > > be, it only knows the measurement that a potentially malicious boot > > > loader felt like giving the kernel previously (e.g. when the kernel > > > was installed). > > > > Even if the kernel has an idea of what the measurement should be, it has > > no way to verify that what it believes to be true is true - any > > malicious code could simply have modified the kernel to believe that > > anything it asks the TPM returns the "correct" answer. > > Right. To achieve the best possible security; you'd need Secure Boot > to ensure that the kernel itself wasn't modified, and then the kernel > establishes a dynamic root of trust itself. You can't rely on Secure Boot because compromised firmware might fail to implement it, so you're back to relying on dynamic trust. > Anything involving a boot loader (e.g. Secure Boot ensure's boot > loader wasn't modified, then boot loader ensure's kernel wasn't > modified, then ....) increases the attack surface for no benefit. I honestly feel like we're talking about different things. Can you describe the attack vector you're concerned about here? > I'm not convinced an external agent can detect "bad/forged > measurement" either. E.g. if a MiTM boot loader always provided a > bad/forged measurement the external agent won't detect it (as the > measurement always matches the expected measurement), and then if the > MiTM boot loader is replaced by a good/honest boot loader the external > agent will decide that the good/honest boot loader is malicious > because its measurement doesn't match the expected bad/forged > measurement. The point of DRTM is that the platform (in the form of an authenticated code module running on the CPU, outside of the control of the OS) performs a measreument of a specific point in time. The policy it's provided with allows an external agent to identify which component of the runtime system is being measured. If an external malicious agent has been executed then the measurement will be different as a result. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Linux DRTM on UEFI platforms 2022-07-05 18:35 ` Daniel P. Smith 2022-07-06 0:03 ` Brendan Trotter @ 2022-08-05 12:53 ` Ard Biesheuvel 1 sibling, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2022-08-05 12:53 UTC (permalink / raw) To: Daniel P. Smith Cc: Matthew Garrett, Daniel Kiper, Alec Brown, Kanth Ghatraju, Ross Philipson, piotr.krol@3mdeb.com, krystian.hebel@3mdeb.com, persaur@gmail.com, Yoder, Stuart, Andrew Cooper, michal.zygowski@3mdeb.com, James Bottomley, lukasz@hawrylko.pl, linux-efi, Linux Kernel Mailing List, The development of GNU GRUB, James Morris On Tue, 5 Jul 2022 at 21:22, Daniel P. Smith <dpsmith@apertussolutions.com> wrote: > > On 6/10/22 12:40, Ard Biesheuvel wrote: ... > > The EFI stub to core kernel handover ABI is private to Linux, > > architecture specific, and subject to change. This is basically the > > point I made before: if you want to boot Linux in EFI mode, you have > > to go via the EFI stub, and the EFI stub is in charge of booting the > > kernel proper. This is why I (we?) suggested some kind of callback > > mechanism, where the EFI stub makes a D-RTM specific call after EBS(), > > but does regain control over the boot flow. > > Literally, this is not how the hardware works nor in line with the > architecture developed by TrenchBoot. By doing the Dynamic Launch Event > (DLE) the system, meaning the CPU, has effectively been reset. The > CPU/Dynamic Configuration Environment (DCE) is expecting to be provided > a kernel to measures, an entrypoint within that kernel to jump to, and > that kernel understands the reset state of the system. As agreed, the > callback approach is the most satisfactory approach to allow the > efi-stub to do its private protocol. Once the flow has switched to a > dynamic launch, the system is now starting the kernel via a dynamic > launch sequence. The dynamic launch entrypoint, sl-stub, is and will be > used as the entrypoint regardless of the firmware, > UEFI/coreboot/oreboot/slimboot/etc., or CPU vendor, Intel/AMD, in use. > Once efi-stub finishes and invokes the callback, its job is complete and > the new dl-handler along with sl-stub from the current patch set will > handle the system and security setup needed before entering into the > kernel proper. > > To help provide clarity, consider the following flows for comparison, > > Normal/existing efi-stub: > EFI -> efi-stub -> head_64.S > > Proposed secure launch: > EFI -> efi-stub -> dl-handler -> [cpu] -> sl_stub ->head_64.S > > Effectively, all this is doing is after efi-stub is done, instead of > jumping into head_64.S, it will call the dynamic launch handler to do > the dynamic launch, let sl_stub bring the system back into an expected > state, and then enter head_64.S just as efi-stub would have done. > OK, understood. > > If we add another entry point into the kernel proper for the Secure > > Launch Entry component to use, we are again exposing an internal ABI > > in a way that limits our future ability to make changes to the EFI <-> > > kernel handover. > > I am not sure how you make that jump, but as I stated above, when > incorporating dynamic launch it is no longer a straight pass from EFI to > kernel proper. The sl-stub is there to provide a common entry point from > the CPU as the result of a dynamic launch, regardless of firmware or > vendor. Once sl-stub is done with its start-of-day setup, it will jump > to the same location efi-stub would have jumped. This means, efi-stub > does everything it always has and is free to change what it does. The > only addition is that it will now enable a call-out to allow secure > launch to do what it needs to do, and then execution returns back to > head_64.S. To be concise, it specifically returns where efi-stub would > have jumped to without removing or circumventing anything from the > existing flow. > Excellent, that answers another question I had regarding the above. > It should also be noted that sl-stub will not be looking to reconfigure > the kernel. It will use the kernel as it was set up by efi-stub. The > only job of sl-stub is to make the world right, measure what efi-stub > provided for measurement, and then enter the kernel proper. The design > of the SLRT structure below is specifically not to bind to anything from > the efi-stub ABI/API. The only information needed to take the > measurements is the location of any config items, their size, and an > identifier for each item. The efi-stub is free to add to and/or remove > from the list of items, along with changing where it is stored, or even > change the format of existing items. The one recommendation, not > requirement, is that the identifiers should not freely be changed. While > it has no impact on sl-stub, it will likely be unpopular with anyone > attempting to keep a manifest of valid efi-stub config items for > attestation verification. It will result in having to maintain a > volatile two-parameter map of (kernel version, identifier) to config > item, at a minimum. > OK, noted. Can we add these recommendations to the header files please? And let's make it a requirement - it's easier to relax it later than the other way around. > <snip/> > > >> First, a short review of what the Secure Launch Resource Table is and > >> its purpose. The SLRT is to provide a platform and kernel agnostic > >> configuration table of the meta-data pertinent to the Secure Launch > >> entry points for the variety of kernels the TrenchBoot project will be > >> seeking to support. The specification for the table is in progress, but > >> the consensus is that it will consist of a header structure followed by > >> a packed series of TLV records. The specification will describe the > >> various types of records, but the ones of interests in this discussion > >> are those that efi-stub would use to record how it configured the > >> environment. > >> > >> The initially proposed TLV record, see below, for EFI configuration > >> information was devised around allowing an EFI bootloader to save > >> multiple config events under a single TLV record. In discussions on the > >> specification thus far, there are questions if it would be better to > >> have a TLV record for each config event or the proposed multiple events > >> per TLV record. It is worth noting that an assumption is being made in > >> the proposed record. The assumption is that a config event will either > >> be setting a configuration value between 1 and 8 bytes, or it will be a > >> data blob for which the address and size will be recorded. The question > >> is whether that covers all actions the efi-stub does or expects that it > >> will have to do in the near future. > >> > >> struct slrt_entry_efi_config_event { > >> struct slrt_entry_hdr hdr; > >> uint32_t identifier; /* EFI bootloader ID */ > >> uint16_t reserved; > >> uint16_t nr_entries; /* Num cfg records */ > >> struct efi_cfg_value values[0]; /* Array of cfg values */ Nit: use [] for flex arrays please - we will become more pedantic about this when using newer compilers. > >> }; > >> > >> struct efi_cfg_value { > >> uint64_t data; /* cfg data (address or value) */ > >> uint32_t size; /* data size if data is an addr */ > >> uint32_t flags; /* 1L<0 IS_ADDR: data is an addr */ > >> char evt_info[8]; /* event info str for TPM event log */ > >> }; > >> > >> Hopefully the general approach here is agreeable, as IMHO it does > >> provide a fairly elegant approach to resolving the issues at hand. > >> Details can always be negotiated to address various implementation > >> concerns. Provided this is acceptable, then everyone here is welcome to > >> provide input on the Secure Launch specification, link forthcoming. > >> > > > > Given that this is EFI, I would expect all these implementation > > details to be exposed via a protocol that the stub can invoke, in a > > way that will likely be similar (or the same?) as the TCG protocol > > used for recording PCR measurements. > > The intent here was not to devise a new EFI protocol. This table is an > agnostic structure that all TrenchBoot Secure Launch implementations > will be using for all firmware environments, and will provide platform > relevant sections like the EFI section outlined above. The table will > inform the dl-handler so that it may take appropriate setup actions for > the dynamic launch. The larger user of the table will be the sl-stub, > which it will use to have an understanding of the world it inherited > from whomever invoked the dynamic launch. > OK. We'll need some useful abstraction for this internally in the stub code, but that is not too relevant for this discussion. (We recently added some code that measures the initrd into the TPM, and having calls to two different kinds of measurement APIs all over the stub is something I'd like to avoid) > > So could you elaborate on the types of actions? Is this simply things > > like the command line, initrd contents, initrd load address, kernel > > load address etc etc? There isn't generally that much going on in the > > stub beyond that. > > Actually, those items are already in well-defined locations for which we > are already taking measurements. The items of concern are the items > being passed or configured that are stored outside the boot params. You mean the x86 specific struct bootparams, right? Not relevant, but just out of interest: I take it you are also measuring the setup_data linked list? This is currently being augmented to carry a RNG seed, which may cause problems for you in the future. > For > instance, ROM files passed to the kernel or EFI environment variables > that efi-stub may have set and/or will be used by the kernel. > Hmm, ok. I'd really like to get a peek at the impact on the code - if we will have hooks all over the place, it is a strong indication that you are intercepting this at the wrong level. Perhaps you'll need to do something along the lines of interposing the boot and runtime services, and measuring the invocations that are relevant to you. ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2022-08-12 5:54 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-29 17:40 Linux DRTM on UEFI platforms Matthew Garrett 2022-03-30 7:02 ` Ard Biesheuvel 2022-03-30 7:11 ` Matthew Garrett 2022-03-30 7:12 ` Ard Biesheuvel 2022-03-30 7:18 ` Matthew Garrett 2022-03-30 7:23 ` Ard Biesheuvel 2022-03-30 7:27 ` Matthew Garrett 2022-03-30 7:39 ` Ard Biesheuvel 2022-03-30 12:46 ` James Bottomley 2022-03-31 0:35 ` Daniel P. Smith 2022-03-31 7:13 ` Ard Biesheuvel 2022-03-31 10:59 ` Heinrich Schuchardt 2022-05-19 20:57 ` Daniel P. Smith 2022-05-19 20:57 ` Daniel P. Smith 2022-06-10 16:40 ` Ard Biesheuvel 2022-07-05 18:35 ` Daniel P. Smith 2022-07-06 0:03 ` Brendan Trotter 2022-07-06 0:12 ` Matthew Garrett 2022-07-07 9:46 ` Daniel P. Smith 2022-07-08 3:36 ` Brendan Trotter 2022-07-08 4:56 ` Matthew Garrett 2022-07-22 17:23 ` Daniel P. Smith 2022-07-23 5:15 ` Brendan Trotter 2022-08-09 10:53 ` Daniel P. Smith 2022-08-10 9:07 ` Brendan Trotter 2022-08-10 17:46 ` Matthew Garrett 2022-08-11 9:55 ` Brendan Trotter 2022-08-11 11:34 ` Daniel Kiper 2022-08-11 18:25 ` Matthew Garrett 2022-08-12 3:22 ` Brendan Trotter 2022-08-12 5:54 ` Matthew Garrett 2022-08-05 12:53 ` Ard Biesheuvel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.