Re: [PATCH 00/13] x86: Trenchboot secure dynamic launch Linux kernel support
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/13] x86: Trenchboot secure dynamic launch Linux kernel support
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 th
Re: [PATCH 00/13] x86: Trenchboot secure dynamic launch Linux kernel support
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu