Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
Paul, Apologies for missing your follow-up questions. Hopefully, the below answers will help. On 1/21/22 16:39, Paul Moore wrote: > On Mon, Dec 6, 2021 at 3:56 PM Paul Moore wrote: >> On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith >> wrote: >>> Hi Paul! >> >> /me waves >> >>> On 11/30/21 8:06 PM, Paul Moore wrote: On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson wrote: > > The larger focus of the Trechboot project (https://github.com/TrenchBoot) > is to > enhance the boot security and integrity in a unified manner. The first > area of > focus has been on the Trusted Computing Group's Dynamic Launch for > establishing > a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root > of > Trust for Measurement). My apologies for such a late reply, but I'm just getting around to looking at this and I have a few questions on the basic design/flow (below) ... >>> >>> No worries, thank you so much for taking the time to review. >>> > The basic flow is: > > - Entry from the dynamic launch jumps to the SL stub So I'm clear, at this point the combined stub+kernel+initramfs+cmdline image has already been loaded into memory and the SL stub is executing, yes? >>> >>> That is correct. >>> As TrenchBoot seems to be focused on boot measurement and not enforcing policy, I'm guessing this is considered out-of-scope (not to mention that the combined stub+kernel image makes this less interesting), but has any thought been given to leveraging the TXT launch control policy, or is it simply an empty run-everything policy? >>> >>> The TrenchBoot model is a bit different and takes a more flexible >>> approach to allow users to build tailored solutions. For instance Secure >>> Launch is able to be used in a configuration that is similar to tboot. >>> Consider the functions of tboot, it has a portion that is the >>> post-launch kernel that handles the handover from the ACM and a portion >>> that provides the Verified Launch policy engine, which is only capable >>> of enforcing policy on what is contained in the Multiboot chain. The >>> TrenchBoot approach is to introduce the Secure Launch capability into a >>> kernel, in this case Linux, to handle the handover from the ACM, and >>> then transition to a running user space that can contain a distribution >>> specific policy enforcement. As an example, the TrenchBoot project >>> contributed to the uroot project a Secure Launch policy engine which >>> enables the creation of an initramfs image which can then be embedded >>> into a minimal configuration Secure Launch Linux kernel ... >> >> Thank you for the answers, that was helpful. >> >> I think I initially misunderstood TrenchBoot, thinking that a Secure >> Launch'd kernel/userspace would be the "normal" OS that would >> transition to multi-user mode and be available for users and >> applications. However, on reading your response it appears that the >> Secure Launch'd kernel/initramfs exists only to verify a secondary >> kernel/initramfs/userspace and then kexec() into that once verified. Yes it can be used in this manner but this is not the only way it was intended to be used. The goal is to enable an integrator, e.g, a distro, to incorporate Linux Secure Launch appropriately for their security needs, though ideally it would be preferred that a standardized approach is adopted by Linux init tooling to provide common experience across distros. Up until the introduction of Secure Launch, the only widely deployed model for DRTM has been to use tboot. Tboot is an MLE/DLME that functions as an exokernel and an intermediate loader for the Runtime OS/MLE. This motivated the first exemplar solution to be a Linux Secure Launch + uroot solution that would provide a similar intermediate loader experience, but with an expanded ability of the uroot to measure additional properties about a system. As a result a distro could use the exemplar to replace tboot, tboot VL policy tools, and VL policy file with a Secure Launch kernel, a u-root initrd (built-in or standalone), and a JSON policy file. By no means was Secure Launch meant to be limited to only being used as an intermediate loader for a Runtime OS. There is nothing that prohibits a Runtime Linux system to be directly started using Secure Launch. Though it should be noted that such a solution would need to be cognizant of the security gap across power-save modes, whereby the OS looses the positive control that it had over the system. It should also be mentioned that one of the motivations behind DRTM late-launch via kexec is to provide a path for dealing with this gap by enabling a late-launch to re-establish a known good state of the system. These all can be considered the advanced use cases for Secure Launch. >>> Finally if your schedule allows it and it is not too much to ask, it >>> would be greatly appreciated if some code review could
Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
On Mon, Dec 6, 2021 at 3:56 PM Paul Moore wrote: > On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith > wrote: > > Hi Paul! > > /me waves > > > On 11/30/21 8:06 PM, Paul Moore wrote: > > > On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson > > > wrote: > > >> > > >> The larger focus of the Trechboot project > > >> (https://github.com/TrenchBoot) is to > > >> enhance the boot security and integrity in a unified manner. The first > > >> area of > > >> focus has been on the Trusted Computing Group's Dynamic Launch for > > >> establishing > > >> a hardware Root of Trust for Measurement, also know as DRTM (Dynamic > > >> Root of > > >> Trust for Measurement). > > > > > > My apologies for such a late reply, but I'm just getting around to > > > looking at this and I have a few questions on the basic design/flow > > > (below) ... > > > > No worries, thank you so much for taking the time to review. > > > > >> The basic flow is: > > >> > > >> - Entry from the dynamic launch jumps to the SL stub > > > > > > So I'm clear, at this point the combined stub+kernel+initramfs+cmdline > > > image has already been loaded into memory and the SL stub is > > > executing, yes? > > > > That is correct. > > > > > As TrenchBoot seems to be focused on boot measurement and not > > > enforcing policy, I'm guessing this is considered out-of-scope (not to > > > mention that the combined stub+kernel image makes this less > > > interesting), but has any thought been given to leveraging the TXT > > > launch control policy, or is it simply an empty run-everything policy? > > > > The TrenchBoot model is a bit different and takes a more flexible > > approach to allow users to build tailored solutions. For instance Secure > > Launch is able to be used in a configuration that is similar to tboot. > > Consider the functions of tboot, it has a portion that is the > > post-launch kernel that handles the handover from the ACM and a portion > > that provides the Verified Launch policy engine, which is only capable > > of enforcing policy on what is contained in the Multiboot chain. The > > TrenchBoot approach is to introduce the Secure Launch capability into a > > kernel, in this case Linux, to handle the handover from the ACM, and > > then transition to a running user space that can contain a distribution > > specific policy enforcement. As an example, the TrenchBoot project > > contributed to the uroot project a Secure Launch policy engine which > > enables the creation of an initramfs image which can then be embedded > > into a minimal configuration Secure Launch Linux kernel ... > > Thank you for the answers, that was helpful. > > I think I initially misunderstood TrenchBoot, thinking that a Secure > Launch'd kernel/userspace would be the "normal" OS that would > transition to multi-user mode and be available for users and > applications. However, on reading your response it appears that the > Secure Launch'd kernel/initramfs exists only to verify a secondary > kernel/initramfs/userspace and then kexec() into that once verified. > > > Finally if your schedule allows it and it is not too much to ask, it > > would be greatly appreciated if some code review could be provided. > > Otherwise thank you for taking the time that you have to review the > > approach. > > I have to admit that I'm not sure I'm the most appropriate person to > review all of the Intel TXT related assembly, but I could give it a > shot as time allows. I would think Intel would be willing to help out > here if one were to ask nicely :) > > Beyond that, and with my new understanding of how TrenchBoot is > supposed to work, I guess my only other concern is how one might > verify the integrity of the Secure Launch environment on the local > system during boot. My apologies if I missed some details about that > in your docs, responses, etc. but is this something that TrenchBoot is > planning on addressing (or has already addressed)? I wanted to follow-up on this thread just in case this last question was lost ... -- paul moore paul-moore.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith wrote: > Hi Paul! /me waves > On 11/30/21 8:06 PM, Paul Moore wrote: > > On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson > > wrote: > >> > >> The larger focus of the Trechboot project (https://github.com/TrenchBoot) > >> is to > >> enhance the boot security and integrity in a unified manner. The first > >> area of > >> focus has been on the Trusted Computing Group's Dynamic Launch for > >> establishing > >> a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root > >> of > >> Trust for Measurement). > > > > My apologies for such a late reply, but I'm just getting around to > > looking at this and I have a few questions on the basic design/flow > > (below) ... > > No worries, thank you so much for taking the time to review. > > >> The basic flow is: > >> > >> - Entry from the dynamic launch jumps to the SL stub > > > > So I'm clear, at this point the combined stub+kernel+initramfs+cmdline > > image has already been loaded into memory and the SL stub is > > executing, yes? > > That is correct. > > > As TrenchBoot seems to be focused on boot measurement and not > > enforcing policy, I'm guessing this is considered out-of-scope (not to > > mention that the combined stub+kernel image makes this less > > interesting), but has any thought been given to leveraging the TXT > > launch control policy, or is it simply an empty run-everything policy? > > The TrenchBoot model is a bit different and takes a more flexible > approach to allow users to build tailored solutions. For instance Secure > Launch is able to be used in a configuration that is similar to tboot. > Consider the functions of tboot, it has a portion that is the > post-launch kernel that handles the handover from the ACM and a portion > that provides the Verified Launch policy engine, which is only capable > of enforcing policy on what is contained in the Multiboot chain. The > TrenchBoot approach is to introduce the Secure Launch capability into a > kernel, in this case Linux, to handle the handover from the ACM, and > then transition to a running user space that can contain a distribution > specific policy enforcement. As an example, the TrenchBoot project > contributed to the uroot project a Secure Launch policy engine which > enables the creation of an initramfs image which can then be embedded > into a minimal configuration Secure Launch Linux kernel ... Thank you for the answers, that was helpful. I think I initially misunderstood TrenchBoot, thinking that a Secure Launch'd kernel/userspace would be the "normal" OS that would transition to multi-user mode and be available for users and applications. However, on reading your response it appears that the Secure Launch'd kernel/initramfs exists only to verify a secondary kernel/initramfs/userspace and then kexec() into that once verified. > Finally if your schedule allows it and it is not too much to ask, it > would be greatly appreciated if some code review could be provided. > Otherwise thank you for taking the time that you have to review the > approach. I have to admit that I'm not sure I'm the most appropriate person to review all of the Intel TXT related assembly, but I could give it a shot as time allows. I would think Intel would be willing to help out here if one were to ask nicely :) Beyond that, and with my new understanding of how TrenchBoot is supposed to work, I guess my only other concern is how one might verify the integrity of the Secure Launch environment on the local system during boot. My apologies if I missed some details about that in your docs, responses, etc. but is this something that TrenchBoot is planning on addressing (or has already addressed)? -- paul moore www.paul-moore.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
Hi Paul! On 11/30/21 8:06 PM, Paul Moore wrote: > On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson > wrote: >> >> The larger focus of the Trechboot project (https://github.com/TrenchBoot) is >> to >> enhance the boot security and integrity in a unified manner. The first area >> of >> focus has been on the Trusted Computing Group's Dynamic Launch for >> establishing >> a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root of >> Trust for Measurement). > > My apologies for such a late reply, but I'm just getting around to > looking at this and I have a few questions on the basic design/flow > (below) ... No worries, thank you so much for taking the time to review. >> The basic flow is: >> >> - Entry from the dynamic launch jumps to the SL stub > > So I'm clear, at this point the combined stub+kernel+initramfs+cmdline > image has already been loaded into memory and the SL stub is > executing, yes? That is correct. > As TrenchBoot seems to be focused on boot measurement and not > enforcing policy, I'm guessing this is considered out-of-scope (not to > mention that the combined stub+kernel image makes this less > interesting), but has any thought been given to leveraging the TXT > launch control policy, or is it simply an empty run-everything policy? The TrenchBoot model is a bit different and takes a more flexible approach to allow users to build tailored solutions. For instance Secure Launch is able to be used in a configuration that is similar to tboot. Consider the functions of tboot, it has a portion that is the post-launch kernel that handles the handover from the ACM and a portion that provides the Verified Launch policy engine, which is only capable of enforcing policy on what is contained in the Multiboot chain. The TrenchBoot approach is to introduce the Secure Launch capability into a kernel, in this case Linux, to handle the handover from the ACM, and then transition to a running user space that can contain a distribution specific policy enforcement. As an example, the TrenchBoot project contributed to the uroot project a Secure Launch policy engine which enables the creation of an initramfs image which can then be embedded into a minimal configuration Secure Launch Linux kernel. This results in a single binary that functions like tboot but with a far richer and more extensible policy engine. With regard to TXT's Launch Control Policy, it is a function of SINIT ACM and so it is still very much possible to be used with Secure Launch. In fact such a configuration has been tested and used. Now it is out of scope in the sense that the tboot project already maintains and provides the lcptools suite for managing LCPs. If there is a requirement to use an LCP, then the lcptools can be used to create a policy to only allow the specific instance(s) of a Secure Launch kernel. >> - SL stub fixes up the world on the BSP >> - For TXT, SL stub wakes the APs, fixes up their worlds >> - For TXT, APs are left halted waiting for an NMI to wake them >> - SL stub jumps to startup_32 >> - SL main locates the TPM event log and writes the measurements of >>configuration and module information into it. > > Since the stub+kernel image are combined it looks like the kernel > measurement comes from the ACM via the MLE measurement into PCR 18, > while the stub generated measurements are extended into PCR 19 or 20 > depending on the configuration, yes? If TXT is launched in Legacy PCR usage mode, then the bzImage, as loaded into memory by the bootloader (GRUB), will be hashed into PCR 18. If it is launched in the default Details and Authorities (DA) PCR usage mode, then the bzImage will be hashed into PCR 17. This is because the kernel has been promoted to being the MLE. > I realize that moving the TXT code into the kernel makes this > difficult (not possible?), but one of the things that was nice about > the tboot based approach (dynamic, early launch) was that it could be > extended to do different types of measurements, e.g. a signing > authority measurement similar to UEFI Secure Boot and PCR 7. If that > is possible, I think it is something worth including in the design, > even if it isn't initially implemented. The only thing that > immediately comes to mind would be a section/region based approach > similar to systemd-boot/gummiboot where the (signed) kernel is kept in > a well known region and verified/measured by the stub prior to jumping > into its start point. Revisiting the tboot-like configuration: the Secure Launch kernel, its configuration (cmdline), and uroot initramfs (which may be embedded or separate) are all part of the MLE started by the ACM. For tboot there is the tboot binary and the VL policy, though uncertain if it was configurable where the policy hash would be extended. Like the tboot VL policy engine, the u-root policy engine is configurable where the measurements are stored. As highlighted, more components are measured as part of Secure Launch than
Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson wrote: > > The larger focus of the Trechboot project (https://github.com/TrenchBoot) is > to > enhance the boot security and integrity in a unified manner. The first area of > focus has been on the Trusted Computing Group's Dynamic Launch for > establishing > a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root of > Trust for Measurement). My apologies for such a late reply, but I'm just getting around to looking at this and I have a few questions on the basic design/flow (below) ... > The basic flow is: > > - Entry from the dynamic launch jumps to the SL stub So I'm clear, at this point the combined stub+kernel+initramfs+cmdline image has already been loaded into memory and the SL stub is executing, yes? As TrenchBoot seems to be focused on boot measurement and not enforcing policy, I'm guessing this is considered out-of-scope (not to mention that the combined stub+kernel image makes this less interesting), but has any thought been given to leveraging the TXT launch control policy, or is it simply an empty run-everything policy? > - SL stub fixes up the world on the BSP > - For TXT, SL stub wakes the APs, fixes up their worlds > - For TXT, APs are left halted waiting for an NMI to wake them > - SL stub jumps to startup_32 > - SL main locates the TPM event log and writes the measurements of >configuration and module information into it. Since the stub+kernel image are combined it looks like the kernel measurement comes from the ACM via the MLE measurement into PCR 18, while the stub generated measurements are extended into PCR 19 or 20 depending on the configuration, yes? I realize that moving the TXT code into the kernel makes this difficult (not possible?), but one of the things that was nice about the tboot based approach (dynamic, early launch) was that it could be extended to do different types of measurements, e.g. a signing authority measurement similar to UEFI Secure Boot and PCR 7. If that is possible, I think it is something worth including in the design, even if it isn't initially implemented. The only thing that immediately comes to mind would be a section/region based approach similar to systemd-boot/gummiboot where the (signed) kernel is kept in a well known region and verified/measured by the stub prior to jumping into its start point. > - Kernel boot proceeds normally from this point. > - During early setup, slaunch_setup() runs to finish some validation >and setup tasks. > - The SMP bringup code is modified to wake the waiting APs. APs vector >to rmpiggy and start up normally from that point. > - SL platform module is registered as a late initcall module. It reads >the TPM event log and extends the measurements taken into the TPM PCRs. I'm sure there is some issue with passing data across boundaries, but is there any reason why the TPM event log needs to be updated out-of-sync with the TPM PCRs? Is is possible to pass the measurements to the SL platform module which would both extend the PCRs and update the TPM event log at the same time? > - SL platform module initializes the securityfs interface to allow >asccess to the TPM event log and TXT public registers. > - Kernel boot finishes booting normally > - SEXIT support to leave SMX mode is present on the kexec path and >the various reboot paths (poweroff, reset, halt). It doesn't look like it's currently implemented, but it looks like eventually you plan to support doing a new DRTM measurement on kexec, is that correct? I'm sure that is something a *lot* of people (including myself) would like to see happen. -- paul moore www.paul-moore.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
The larger focus of the Trechboot project (https://github.com/TrenchBoot) is to enhance the boot security and integrity in a unified manner. The first area of focus has been on the Trusted Computing Group's Dynamic Launch for establishing a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root of Trust for Measurement). The project has been and continues to work on providing a unified means to Dynamic Launch that is a cross-platform (Intel and AMD) and cross-architecture (x86 and Arm), with our recent involvment in the upcoming Arm DRTM specification. The order of introducing DRTM to the Linux kernel follows the maturity of DRTM in the architectures. Intel's Trusted eXecution Technology (TXT) is present today and only requires a preamble loader, e.g. a boot loader, and an OS kernel that is TXT-aware. AMD DRTM implementation has been present since the introduction of AMD-V but requires an additional component that is AMD specific and referred to in the specification as the Secure Loader, which the TrenchBoot project has an active prototype in development. Finally Arm's implementation is in specification development stage and the project is looking to support it when it becomes available. The approach that the TrenchBoot project is taking requires the Linux kernel to be directly invoked by the Dynamic Launch. The Dynamic Launch will be initiated by a boot loader with associated support added to it, for example the first targeted boot loader will be GRUB2. An integral part of establishing the DRTM involves measuring everything that is intended to be run (kernel image, initrd, etc) and everything that will configure that kernel to run (command line, boot params, etc) into specific PCRs, the DRTM PCRs (17-22), in the TPM. Another key aspect is the Dynamic Launch is rooted in hardware, that is to say the hardware (CPU) is what takes the first measurement for the chain of integrity measurements. On Intel this is done using the GETSEC instruction provided by Intel's TXT and the SKINIT instruction provided by AMD's AMD-V. Information on these technologies can be readily found online. This patchset introduces Intel TXT support. To enable the kernel to be launched by GETSEC, a stub must be built into the setup section of the compressed kernel to handle the specific state that the dynamic launch process leaves the BSP in. Also this stub must measure everything that is going to be used as early as possible. This stub code and subsequent code must also deal with the specific state that the dynamic launch leaves the APs in. A quick note on terminology. The larger open source project itself is called Trenchboot, which is hosted on Github (links below). The kernel feature enabling the use of the x86 technology is referred to as "Secure Launch" within the kernel code. As such the prefixes sl_/SL_ or slaunch/SLAUNCH will be seen in the code. The stub code discussed above is referred to as the SL stub. The new feature starts with patch #4. There are several preceeding patches before that. Patches 1 and 2 are fixes to an earlier patch set that itroduced the x86 setup_data type setup_indirect. Patch 3 was authored by Arvind Sankar. There is no further status on this patch at this point but Secure Launch depends on it so it is included with the set. The basic flow is: - Entry from the dynamic launch jumps to the SL stub - SL stub fixes up the world on the BSP - For TXT, SL stub wakes the APs, fixes up their worlds - For TXT, APs are left halted waiting for an NMI to wake them - SL stub jumps to startup_32 - SL main locates the TPM event log and writes the measurements of configuration and module information into it. - Kernel boot proceeds normally from this point. - During early setup, slaunch_setup() runs to finish some validation and setup tasks. - The SMP bringup code is modified to wake the waiting APs. APs vector to rmpiggy and start up normally from that point. - SL platform module is registered as a late initcall module. It reads the TPM event log and extends the measurements taken into the TPM PCRs. - SL platform module initializes the securityfs interface to allow asccess to the TPM event log and TXT public registers. - Kernel boot finishes booting normally - SEXIT support to leave SMX mode is present on the kexec path and the various reboot paths (poweroff, reset, halt). Links: The Trenchboot project including documentation: https://github.com/trenchboot Intel TXT is documented in its own specification and in the SDM Instruction Set volume: https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf https://software.intel.com/en-us/articles/intel-sdm AMD SKINIT is documented in the System Programming manual: https://www.amd.com/system/files/TechDocs/24593.pdf GRUB2 pre-launch support patchset (WIP): https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00011.html Thanks Ross Philipson and Daniel P.
