| Message ID | 1600959521-24158-1-git-send-email-ross.philipson@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86: Trenchboot secure dynamic launch Linux kernel support | expand |
On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote: > The Trenchboot project focus on boot security has led to the enabling of > the Linux kernel to be directly invocable by the x86 Dynamic Launch > instruction(s) for establishing a Dynamic Root of Trust for Measurement > (DRTM). The dynamic launch will be initiated by a boot loader with What is "the dynamic launch"? > 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. Why not both Intel and AMD? You should explain this in the cover letter. I'd be more motivated to review and test a full all encompassing x86 solution. It would increase the patch set size but would also give it a better test coverage, which I think would be a huge plus in such a complex patch set. > 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. This is > analogous to the EFI stub that is found in the same area. Also this stub How is it analogous? > 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. What is "the specific state"? > 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. Is this only for Trenchboot? I'm a bit lost. What is it anyway? > The basic flow is: > > - Entry from the dynamic launch jumps to the SL stub > - SL stub fixes up the world on the BSP What is "SL"? > - 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 runs to measure configuration and module information into the > DRTM PCRs. It also locates the TPM event log. > - Kernel boot proceeds normally from this point. > - During early setup, slaunch_setup() runs to finish some validation > and setup tasks. What are "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. > - Kernel boot finishes booting normally > - SL securityfs module is present to allow reading and writing of the > TPM event log. What is SL securityfs module? Why is it needed? We already have securityfs file for the event log. Why it needs to be writable? > - SEXIT support to leave SMX mode is present on the kexec path and > the various reboot paths (poweroff, reset, halt). What SEXIT do and why it is required on the kexec path? /Jarkko
On 9/25/20 1:30 AM, Jarkko Sakkinen wrote: > On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote: >> The Trenchboot project focus on boot security has led to the enabling of >> the Linux kernel to be directly invocable by the x86 Dynamic Launch >> instruction(s) for establishing a Dynamic Root of Trust for Measurement >> (DRTM). The dynamic launch will be initiated by a boot loader with > > What is "the dynamic launch"? Dynamic launch is the term used to reference the event/process of restarting a system without reboot to establish the DRTM. It is defined in the TCG Glossary[1], is discussed in detail in the TCG D-RTM Architecture specification[2], and covered in minimal detail in sections 9.5.5 and 34.2 of the TCG TPM2.0 Architecture specification[3]. [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture_v1-0_Published_06172013.pdf [3] https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf >> 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. > > Why not both Intel and AMD? You should explain this in the cover letter. The work for this is split across different teams with different resourcing levels resulting in one organization working Intel and another working AMD. This then raised the concern over submitting a single patch set developed by two groups pseudo-independently. In this situation the result would be patches being submitted from one organization that had no direct development or testing and therefore could not sign off on a subset of the patches being submitted. > I'd be more motivated to review and test a full all encompassing x86 > solution. It would increase the patch set size but would also give it > a better test coverage, which I think would be a huge plus in such a > complex patch set. We would not disagree with those sentiments but see the previous response about the conflict that exists. >> 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. This is >> analogous to the EFI stub that is found in the same area. Also this stub > > How is it analogous? It is analogous as we used it as the pattern to follow for adding a configurable entry point to the kernel. There was a discussion on this when we published the RFC patches[4]. [4] https://lkml.org/lkml/2020/3/25/982 >> 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. > > What is "the specific state"? The details are a bit more than I would prefer to explain here, I would recommend reading section 2.3 and 2.4 of Intel's TXT Software Development Guide[5] for all the details of the state and the prescribed initialization sequence. [5] https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf >> 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. > > Is this only for Trenchboot? I'm a bit lost. What is it anyway? TrenchBoot is a meta-project that is working to bring a unified approach to using DRTM across CPU implementations and open source projects. Currently we are working to integrate a dynamic launch preamble (the code that sets up for calling the dynamic launch CPU instruction) in GRUB, building an open AMD Secure Loader that aligns with how Intel's SINIT ACM hands off to an MLE, bring the first directly launchable implementation to Linux (Secure Launch) with Xen being the next directly launchable implementation, providing the u-root project a secure launch initramfs init routine to demonstrate a policy driven measurement and attestation framework that can be used in conjunction with a Secure Launch kernel. >> The basic flow is: >> >> - Entry from the dynamic launch jumps to the SL stub >> - SL stub fixes up the world on the BSP > > What is "SL"? As mentioned above, it is just shorthand for Secure Launch. >> - 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 runs to measure configuration and module information into the >> DRTM PCRs. It also locates the TPM event log. >> - Kernel boot proceeds normally from this point. >> - During early setup, slaunch_setup() runs to finish some validation >> and setup tasks. > > What are "some" validation and setup tasks? The validation and setup steps are to ensure the environment was setup in a manner that we expected as outlined in the Intel TXT Software Development guide[4]. At this point these are, - Ensure that SENTER completed successfully and was not initiated by TBOOT. - Check that the private MMIO register bank is available. - Fetch values needed from the TXT heap for later operations. - Verify the PMR values cover the MLE and other memory regions that need to be secure. - Reserve certain TXT specific areas of physical memory. - Fetch the copy of the DMAR table from the TXT heap to provide to the IOMMU driver later. >> - The SMP bringup code is modified to wake the waiting APs. APs vector >> to rmpiggy and start up normally from that point. >> - Kernel boot finishes booting normally >> - SL securityfs module is present to allow reading and writing of the >> TPM event log. > > What is SL securityfs module? Why is it needed? We already have > securityfs file for the event log. Why it needs to be writable? The securityfs nodes provides access to the TXT registers to inspect the details from the dynamic launch and access to the DRTM event log. The DRTM event log is setup by the DRTM process and is a different/separate event log from the SRTM/UEFI event log. We need write access for use cases where the Secure Launch kernel is being used as an intermediate launch kernel where additional measurements about the final target environment are being collected. >> - SEXIT support to leave SMX mode is present on the kexec path and >> the various reboot paths (poweroff, reset, halt). > > What SEXIT do and why it is required on the kexec path? The SEXIT instruction "exits" SMX mode. The why is because when in SMX mode the CPU has a set of behaviors different than what is typically expected, especially for SMP management. As good custodians, this ensures that the system is in a usable state for a follow-on kernel that is not SMX/Secure Launch aware. From a security use case perspective, leaving SMX mode disables access to localities 1-3 of the TPM. This essentially "locks" the values in the DRTM PCRs from further modification/extends until another dynamic launch event is fired which will in turn result in the DRTM PCRs being reset. > /Jarkko >
On Fri, Sep 25, 2020 at 05:32:50PM -0400, Daniel P. Smith wrote: > The work for this is split across different teams with different > resourcing levels resulting in one organization working Intel and > another working AMD. This then raised the concern over submitting a > single patch set developed by two groups pseudo-independently. In this > situation the result would be patches being submitted from one > organization that had no direct development or testing and therefore > could not sign off on a subset of the patches being submitted. Not sure if internal team structures qualify as a techical argument for upstream code. > > I'd be more motivated to review and test a full all encompassing x86 > > solution. It would increase the patch set size but would also give it > > a better test coverage, which I think would be a huge plus in such a > > complex patch set. > > We would not disagree with those sentiments but see the previous > response about the conflict that exists. At minimum, you have to make the case that the AMD support is easy to tackle in to the framework of things you have later on. /Jarkko
The Trenchboot project focus on boot security has led to the enabling of the Linux kernel to be directly invocable by the x86 Dynamic Launch instruction(s) for establishing a Dynamic Root of Trust for Measurement (DRTM). 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. This is analogous to the EFI stub that is found in the same area. 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 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 runs to measure configuration and module information into the DRTM PCRs. It also locates the TPM event log. - 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. - Kernel boot finishes booting normally - SL securityfs module is present to allow reading and writing of the TPM event log. - 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 Daniel P. Smith (4): x86: Add early TPM TIS/CRB interface support for Secure Launch x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch x86: Add early general TPM interface support for Secure Launch x86: Secure Launch adding event log securityfs Ross Philipson (9): x86: Secure Launch Kconfig x86: Secure Launch main header file x86: Add early SHA support for Secure Launch early measurements 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 | 9 + arch/x86/Kconfig | 36 ++ arch/x86/boot/compressed/Makefile | 8 + arch/x86/boot/compressed/early_sha1.c | 104 ++++ arch/x86/boot/compressed/early_sha1.h | 17 + arch/x86/boot/compressed/early_sha256.c | 6 + arch/x86/boot/compressed/early_sha512.c | 6 + arch/x86/boot/compressed/head_64.S | 34 + arch/x86/boot/compressed/kernel_info.S | 7 + arch/x86/boot/compressed/sl_main.c | 390 ++++++++++++ arch/x86/boot/compressed/sl_stub.S | 606 ++++++++++++++++++ arch/x86/boot/compressed/tpm/crb.c | 304 +++++++++ arch/x86/boot/compressed/tpm/crb.h | 20 + arch/x86/boot/compressed/tpm/tis.c | 215 +++++++ arch/x86/boot/compressed/tpm/tis.h | 46 ++ arch/x86/boot/compressed/tpm/tpm.c | 145 +++++ arch/x86/boot/compressed/tpm/tpm.h | 48 ++ arch/x86/boot/compressed/tpm/tpm1.h | 112 ++++ arch/x86/boot/compressed/tpm/tpm1_cmds.c | 99 +++ arch/x86/boot/compressed/tpm/tpm2.h | 89 +++ arch/x86/boot/compressed/tpm/tpm2_auth.c | 44 ++ arch/x86/boot/compressed/tpm/tpm2_auth.h | 21 + arch/x86/boot/compressed/tpm/tpm2_cmds.c | 145 +++++ arch/x86/boot/compressed/tpm/tpm2_constants.h | 66 ++ arch/x86/boot/compressed/tpm/tpm_buff.c | 121 ++++ arch/x86/boot/compressed/tpm/tpm_common.h | 127 ++++ arch/x86/boot/compressed/tpm/tpmbuff.h | 34 + arch/x86/boot/compressed/tpm/tpmio.c | 51 ++ arch/x86/include/asm/realmode.h | 3 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/asm-offsets.c | 16 + arch/x86/kernel/reboot.c | 10 + arch/x86/kernel/setup.c | 3 + arch/x86/kernel/slaunch.c | 856 ++++++++++++++++++++++++++ arch/x86/kernel/smpboot.c | 86 +++ arch/x86/realmode/rm/header.S | 3 + arch/x86/realmode/rm/trampoline_64.S | 37 ++ drivers/char/tpm/tpm-chip.c | 13 +- drivers/iommu/intel/dmar.c | 4 + include/linux/sha512.h | 21 + include/linux/slaunch.h | 544 ++++++++++++++++ kernel/kexec_core.c | 4 + lib/sha1.c | 4 + lib/sha512.c | 209 +++++++ 44 files changed, 4722 insertions(+), 2 deletions(-) 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/early_sha512.c 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/boot/compressed/tpm/crb.c create mode 100644 arch/x86/boot/compressed/tpm/crb.h create mode 100644 arch/x86/boot/compressed/tpm/tis.c create mode 100644 arch/x86/boot/compressed/tpm/tis.h create mode 100644 arch/x86/boot/compressed/tpm/tpm.c create mode 100644 arch/x86/boot/compressed/tpm/tpm.h create mode 100644 arch/x86/boot/compressed/tpm/tpm1.h create mode 100644 arch/x86/boot/compressed/tpm/tpm1_cmds.c create mode 100644 arch/x86/boot/compressed/tpm/tpm2.h create mode 100644 arch/x86/boot/compressed/tpm/tpm2_auth.c create mode 100644 arch/x86/boot/compressed/tpm/tpm2_auth.h create mode 100644 arch/x86/boot/compressed/tpm/tpm2_cmds.c create mode 100644 arch/x86/boot/compressed/tpm/tpm2_constants.h create mode 100644 arch/x86/boot/compressed/tpm/tpm_buff.c create mode 100644 arch/x86/boot/compressed/tpm/tpm_common.h create mode 100644 arch/x86/boot/compressed/tpm/tpmbuff.h create mode 100644 arch/x86/boot/compressed/tpm/tpmio.c create mode 100644 arch/x86/kernel/slaunch.c create mode 100644 include/linux/sha512.h create mode 100644 include/linux/slaunch.h create mode 100644 lib/sha512.c