| Message ID | 1630070917-9896-1-git-send-email-ross.philipson@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86: Trenchboot secure dynamic launch Linux kernel support | expand |
On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson <ross.philipson@oracle.com> 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.
Hi Paul! On 11/30/21 8:06 PM, Paul Moore wrote: > On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson > <ross.philipson@oracle.com> 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 for tboot. The approach taken was to model after DA and put binaries into 17 and configuration into 18. Later there were requirements to isolate certain measurements. For the time this is provided through kconfig to move config to 19 and initrd to 20. In the future if/when additional measurements are incorporated, such as signing keys that are embedded into the kernel, then it may be necessary to provide a means to configure PCR usage at runtime. >> - 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? Without rehashing the issues around TPM usage from the stub, the core issue is that measurements need to be collected before usage which is at a time when access to the TPM is not possible at this time. Thus the measurements need to be collected and persisted in a location where they can be retrieved when the main kernel is in control. It was felt using the DRTM TPM log was a natural place as it persists all the info necessary to record the measurements by the SL platform module. Though it does result in there being two non-event entries to exist in the log but those are standardized such that any TCG compliant log parser should ignore them. With the explanation of why it was done aside, if there is another location that is preferred which can provide the necessary guarantees, then there is no reason why they could not be switched to that location. >> - 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. Correct, relaunch is not currently implemented but has always been planned as relaunch enables DRTM late-launch use cases. For a few reasons this is being elevated in priority and as a result there is a short-term solution to quickly enable relaunch with longer term direct integration into kexec. 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. V/r, Daniel P. Smith Apertus Solutions, LLC
On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith <dpsmith@apertussolutions.com> 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 > > <ross.philipson@oracle.com> 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)?
On Mon, Dec 6, 2021 at 3:56 PM Paul Moore <paul@paul-moore.com> wrote: > On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith > <dpsmith@apertussolutions.com> 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 > > > <ross.philipson@oracle.com> 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, 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 <paul@paul-moore.com> wrote: >> On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith >> <dpsmith@apertussolutions.com> 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 >>>> <ross.philipson@oracle.com> 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 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 ... To continue from the answer above and lead into answering your question I would first point to a presentation I gave at LPC 2020, Advanced Applications of DRTM with TrenchBoot[1]. There I walked through how Secure Launch could be used for different early-launch and late-launch DRTM solutions. Under the late-launch solutions there is the "Secure Upgrade" solutions. What I laid out there is that DRTM could be used to launch an "Upgrade Environment" which could be locally or remotely verified and provide a known-good and clean environment to upgrade a system. What an implementation of that actually looks like can be seen in the presentation by Brain Payne and myself at FOSDEM 2021, Secure Upgrades with DRTM[2]. In this presentation the concept of a Management MLE is introduced to provide a secure means to upgrade the Runtime MLE along with its related policy and sealing measurements. Now the above, like most local verification, relies on the unseal operation as the means of local attestation. Using unseal is strong but the reality is that remote attestation is stronger. The problem is that remote attestation is often built as an enterprise solutions requiring a central server/service under the control of an authority that decides what is good or bad. Often the average user either does not have access to such a service or does not desire to out-source control over their system. To address this I am collaborating with 3mdeb on their Fobnail product[3][4][5] to deliver an "attestation server in your pocket" capability that is accessible and usable by the average user. The answer so far is around solutions that were built from/around the TrenchBoot project but Linux Secure Launch does not require new, special user solutions. These solutions have been developed because DRTM enables them to exist, not that they are the only ways Linux Secure Launch can be utilized. For instance it is possible to setup a Clevis[6] based LUKS full disk encryption setup using clevis' TPM2 PIN, where the TPM2 PIN configuration uses the DRTM PCRs (17-22) as part of sealing PCRs for the encryption key. [1] https://lpc.events/event/7/contributions/739/ [2] https://archive.fosdem.org/2021/schedule/event/firmware_suwd/ [3] https://blog.3mdeb.com/2021/2021-10-28-fobnail-promotion/ [4] https://blog.3mdeb.com/2021/2021-12-15-fobnail_2nd_phase/ [5] https://fobnail.3mdeb.com/ [6] https://github.com/latchset/clevis V/r, Daniel P. Smith
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. Smith Changes in v2: - Modified 32b entry code to prevent causing relocations in the compressed kernel. - Dropped patches for compressed kernel TPM PCR extender. - Modified event log code to insert log delimiter events and not rely on TPM access. - Stop extending PCRs in the early Secure Launch stub code. - Removed Kconfig options for hash algorithms and use the algorithms the ACM used. - Match Secure Launch measurement algorithm use to those reported in the TPM 2.0 event log. - Read the TPM events out of the TPM and extend them into the PCRs using the mainline TPM driver. This is done in the late initcall module. - Allow use of alternate PCR 19 and 20 for post ACM measurements. - Add Kconfig constraints needed by Secure Launch (disable KASLR and add x2apic dependency). - Fix testing of SL_FLAGS when determining if Secure Launch is active and the architecture is TXT. - Use SYM_DATA_START_LOCAL macros in early entry point code. - Security audit changes: - Validate buffers passed to MLE do not overlap the MLE and are properly laid out. - Validate buffers and memory regions used by the MLE are protected by IOMMU PMRs. - Force IOMMU to not use passthrough mode during a Secure Launch. - Prevent KASLR use during a Secure Launch. Changes in v3: - Introduce x86 documentation patch to provide background, overview and configuration/ABI information for the Secure Launch kernel feature. - Remove the IOMMU patch with special cases for disabling IOMMU passthrough. Configuring the IOMMU is now a documentation matter in the previously mentioned new patch. - Remove special case KASLR disabling code. Configuring KASLR is now a documentation matter in the previously mentioned new patch. - Fix incorrect panic on TXT public register read. - Properly handle and measure setup_indirect bootparams in the early launch code. - Use correct compressed kernel image base address when testing buffers in the early launch stub code. This bug was introduced by the changes to avoid relocation in the compressed kernel. - Use CPUID feature bits instead of CPUID vendor strings to determine if SMX mode is supported and the system is Intel. - Remove early NMI re-enable on the BSP. This can be safely done later on the BSP after an IDT is setup. Changes in v4: - Expand the cover letter to provide more context to the order that DRTM support will be added. - Removed debug tracing in TPM request locality funciton and fixed local variable declarations. - Fixed missing break in default case in slmodule.c. - Reworded commit messages in patches 1 and 2 per suggestions. Arvind Sankar (1): x86/boot: Place kernel_info at a fixed offset Daniel P. Smith (2): x86: Add early SHA support for Secure Launch early measurements x86: Secure Launch late initcall platform module Ross Philipson (11): x86/boot: Fix memremap of setup_indirect structures x86/boot: Add setup_indirect support in early_memremap_is_setup_data Documentation/x86: Secure Launch kernel documentation x86: Secure Launch Kconfig x86: Secure Launch main header file x86: Secure Launch kernel early boot stub x86: Secure Launch kernel late boot stub x86: Secure Launch SMP bringup support kexec: Secure Launch kexec SEXIT support reboot: Secure Launch SEXIT support on reboot paths tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Documentation/x86/boot.rst | 13 + Documentation/x86/index.rst | 1 + Documentation/x86/secure-launch.rst | 716 ++++++++++++++++++++++++++++++++ arch/x86/Kconfig | 32 ++ arch/x86/boot/compressed/Makefile | 3 + arch/x86/boot/compressed/early_sha1.c | 103 +++++ arch/x86/boot/compressed/early_sha1.h | 17 + arch/x86/boot/compressed/early_sha256.c | 7 + arch/x86/boot/compressed/head_64.S | 37 ++ arch/x86/boot/compressed/kernel_info.S | 53 ++- arch/x86/boot/compressed/kernel_info.h | 12 + arch/x86/boot/compressed/sl_main.c | 549 ++++++++++++++++++++++++ arch/x86/boot/compressed/sl_stub.S | 685 ++++++++++++++++++++++++++++++ arch/x86/boot/compressed/vmlinux.lds.S | 6 + arch/x86/include/asm/realmode.h | 3 + arch/x86/kernel/Makefile | 2 + arch/x86/kernel/asm-offsets.c | 19 + arch/x86/kernel/e820.c | 31 +- arch/x86/kernel/kdebugfs.c | 32 +- arch/x86/kernel/ksysfs.c | 56 ++- arch/x86/kernel/reboot.c | 10 + arch/x86/kernel/setup.c | 26 +- arch/x86/kernel/slaunch.c | 531 +++++++++++++++++++++++ arch/x86/kernel/slmodule.c | 494 ++++++++++++++++++++++ arch/x86/kernel/smpboot.c | 86 ++++ arch/x86/mm/ioremap.c | 34 +- arch/x86/realmode/rm/header.S | 3 + arch/x86/realmode/rm/trampoline_64.S | 37 ++ drivers/char/tpm/tpm-chip.c | 9 +- drivers/iommu/intel/dmar.c | 4 + include/linux/slaunch.h | 532 ++++++++++++++++++++++++ kernel/kexec_core.c | 4 + lib/crypto/sha256.c | 8 + lib/sha1.c | 4 + 34 files changed, 4110 insertions(+), 49 deletions(-) create mode 100644 Documentation/x86/secure-launch.rst create mode 100644 arch/x86/boot/compressed/early_sha1.c create mode 100644 arch/x86/boot/compressed/early_sha1.h create mode 100644 arch/x86/boot/compressed/early_sha256.c create mode 100644 arch/x86/boot/compressed/kernel_info.h create mode 100644 arch/x86/boot/compressed/sl_main.c create mode 100644 arch/x86/boot/compressed/sl_stub.S create mode 100644 arch/x86/kernel/slaunch.c create mode 100644 arch/x86/kernel/slmodule.c create mode 100644 include/linux/slaunch.h