| Message ID | 1645070085-14255-1-git-send-email-ross.philipson@oracle.com |
|---|---|
| Headers | show |
| Series | x86: Trenchboot secure dynamic launch Linux kernel support | expand |
Hi Dave! Please find a response that will hopefully address the questions raised. The answers were meant to be thorough but succinct, though if there is any areas that are not clear for anyone, please feel free to ask. This response and any further questions for clarity will be incorporated into the documentation patch and the cover letter for the next version of the series. On 2/23/22 12:45, Dave Hansen wrote: > On 2/16/22 19:54, Ross Philipson wrote: >> The larger focus of the TrenchBoot 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. > > What problem is this patch series solving? Is the same problem solved > in a different way in the kernel today? What is wrong with that > solution? What effects will end users see if they apply this series? What problem is the Secure Launch patch series solving? ------------------------------------------------------- * This patch series begins solving the problem of maintaining a robust multi-architecture path of entry from DRTM into the Linux kernel. * DRTM (Dynamic Root of Trust for Measurement) is a strong security capability that has been used in niche OS environments, including OpenXT and Qubes. For more than a decade, some have successfully deployed Linux with DRTM, but popular Linux distros have not yet used DRTM. * The TrenchBoot project was started to improve the usability of DRTM with Open-Source systems software (e.g. Linux, Xen) on hardware architectures that provide a DRTM capability, e.g Intel x86, AMD x86, Arm, and OpenPOWER. * Microsoft Secured Core enterprise PCs use DRTM as a cornerstone of establishing device integrity, optionally validated by Azure Attestation. Devices with DRTM and Linux Secure Launch will have necessary building blocks for attestation to local and remote services, including Azure. * TrenchBoot contributors have collaborated with Arm on the development of their recently released DRTM specification [1], which can enable Windows VBS (virtualization-based security) and Linux Secure Launch capabilities, on DRTM-capable Arm devices such as Microsoft Secured Core PCs. * From 2018-2020, possibly motivated by DRTM requirements in MS Secured Core, Intel Hardware Shield[2] introduced vPro hardware and firmware features for SMM (System Management Mode) trustworthiness via attestable isolation between operating systems and SMM. DRTM prevents any DMA interference during the Intel Hardware Shield PPAM integrity report exchange with Linux. [1] https://developer.arm.com/documentation/den0113/latest [2] https://www.intel.com/content/dam/www/central-libraries/us/en/documents/drtm- based-computing-whitepaper.pdf Is the same problem solved in a different way in the kernel today? ------------------------------------------------------------------ * Today the only way to start Linux via DRTM is with Intel's tboot exokernel. * The Secure Launch patch series was designed to co-exist with the existing tboot extensions in the Linux kernel as to not to disrupt existing users of tboot. * The first beta release of the Arm DRTM specification was just made public on February 17th, 2022. Obviously there are currently no implementations available yet. What is wrong with that solution? --------------------------------- * A short discussion over tboot can be found in the Overview section of secure_launch_overview.rst in the documentation patch, which is v5 patch 02/12. * Functionally tboot's primary deficiency is that it is an Intel-only solution. * There is no support for the AMD/Hygon, whose SKINIT capability has been around nearly as long as Intel TXT. * The security merits of tboot's approach could be debated endlessly by security researchers depending on their view of trust and security. What effects will end users see if they apply this series? ---------------------------------------------------------- * To provide a full answer, the capability can be completely disabled via the Kconfig system resulting in no new code paths. * The other case is when a kernel is built with Secure Launch enabled and in this case there are two relevant aspects, impacts to user experience and the benefits the user will gain. * As to the impacts to user experience, the end users should see no effects in the launch of the kernel from this series. * One of the primary goals for this series was to minimize change to the kernel boot flow and to ensure the capability was benign if compiled in but not enabled/used. * When the bootloader is configured to launch the kernel via DRTM, again there will be little to no effect on the user experience. There are a few CPU behavior differences that result from doing a DRTM but their effect is only seen by Linux internals, for which this series makes the kernel aware. * The benefit is that it removes having to trust all the second and third party code in the UEFI boot chain. For instance during the Boothole vulnerability situation, Boothole had a near zero if not a zero impact for DRTM systems, i.e. it could not be used to compromise nor load a bad kernel. * Removing the need to trust every driver, service, and setup code in firmware is not the only benefit as DRTM provides several use cases that are not otherwise possible. Please see my response to Paul Moore or visit trenchboot.org/events to see the numerous talks on usages and capabilities that are possible because of DRTM. V/r, Daniel P. Smith
The larger focus of the TrenchBoot 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. This patchset provides detailed documentation of DRTM, the approach used for adding the capbility, and relevant API/ABI documentation. In addition to the documentation the patch set introduces Intel TXT support as the first platform for Linux Secure Launch. 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 Dynamic Launch 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 Secure Launch feature starts with patch #2. Patch #1 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. 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. Changes in v5: - Comprehensive documentation rewrite. - Use boot param loadflags to communicate Secure Launch status to kernel proper. - Fix incorrect check of X86_FEATURE_BIT_SMX bit. - Rename the alternate details and authorities PCR support. - Refactor the securityfs directory and file setup in slmodule.c. - Misc. cleanup from internal code reviews. - Use reverse fir tree format for variables. 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 (9): 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/security/index.rst | 1 + Documentation/security/launch-integrity/index.rst | 10 + .../security/launch-integrity/principles.rst | 313 ++++++++++ .../launch-integrity/secure_launch_details.rst | 552 +++++++++++++++++ .../launch-integrity/secure_launch_overview.rst | 214 +++++++ Documentation/x86/boot.rst | 21 + arch/x86/Kconfig | 34 + arch/x86/boot/compressed/Makefile | 3 + arch/x86/boot/compressed/early_sha1.c | 97 +++ 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 | 556 +++++++++++++++++ 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/include/uapi/asm/bootparam.h | 1 + arch/x86/kernel/Makefile | 2 + arch/x86/kernel/asm-offsets.c | 19 + arch/x86/kernel/reboot.c | 10 + arch/x86/kernel/setup.c | 3 + arch/x86/kernel/slaunch.c | 536 ++++++++++++++++ arch/x86/kernel/slmodule.c | 493 +++++++++++++++ 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 | 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, 4367 insertions(+), 5 deletions(-) create mode 100644 Documentation/security/launch-integrity/index.rst create mode 100644 Documentation/security/launch-integrity/principles.rst create mode 100644 Documentation/security/launch-integrity/secure_launch_details.rst create mode 100644 Documentation/security/launch-integrity/secure_launch_overview.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