From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f50.google.com (mail-dl1-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E7C53F788A for ; Fri, 15 May 2026 21:14:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778879700; cv=none; b=Nni8I9u69eJQs9pp8yQ2aIS7OQQkU3A5z6KhR3ifg8PE7p6EwwEMvBcMyyt29PoIFGcLPaGVtLar2RNl3ixCIaYhGCeSK8Xiix5fygrOhw5myZ1K6hyn5+7do1uqY3oG5sLhKMBfVVgLXNPQJvqI+23lBDTh1u8FOL31rHW9e8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778879700; c=relaxed/simple; bh=9YS4BuHjnfo+1IReQ3Kb+NmIPLFdp9Qh7Ox7isDv3NQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PLBfavyC/UpZdHfNwujrAyLsI93FO4wd+tVKeDm5OrrWtOkRYVoSbxn7Pky+ZvK3wmOEh6YhXasVGkM5RnFVe8L696O4iLJVKXjob4qg33lYQFfHTGqY8hgXd1FNdYz2tPNsplqeGpR9tkZlbaZOcZ7ZxHKYiZjYY7udVxd1g68= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qCrdw4Ik; arc=none smtp.client-ip=74.125.82.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qCrdw4Ik" Received: by mail-dl1-f50.google.com with SMTP id a92af1059eb24-12c88e5f4aeso129686c88.0 for ; Fri, 15 May 2026 14:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778879696; x=1779484496; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yYV487dim1u7McKHcszztZC/VNez+ruEau/ZSoQzK6U=; b=qCrdw4IkzM+j5ub2ZAZRhtcI5ZeBerH/N3TylpfGqhdbGlvZSp/9i1BoGDwUulwzo9 ih/aJUNsCDMS6I+Q7FeWj6PxXeX4IvoICuH44XRwqTRZlnv175fpVOcQsPHELZ1J/TPA xGhllREnLYSEjsHuTXm9/loijMK3zFRrFxkKc87as44299Fkzfm7SJvFBznYMdUehXPd svCpwIkr40vc9bhvSwLk5GbbZ3xWupFtjA6HGqwoU1XkeATVDX3AFNx1so1Vkcuv7PyU 4jgw9BxWdIWwX8st9gJM5b1CaIlqwwkW3IlY+i/O7Zhtqc5JY5QNsHue9JR4N3xcJkWV PfrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778879696; x=1779484496; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yYV487dim1u7McKHcszztZC/VNez+ruEau/ZSoQzK6U=; b=rIipR5Hba//M4WUTc98akYy4rcr5Un0g0h28X9spdu/tQBp+ehy6BXzZQo7Tllf+es ZGn4Vx7+Hg8Fy91mhjErOR8/73ZzQEKcUZ8g0ixo3PYqe2WYoKV2p8AmtmCwL9YIlnch MBEGQtJi5JI1JenVSBwKYFRlj36DUXfGQTV5gdutwWkiFW70iVe1RkXz5+cfYWttD670 zZH05RvGRYdNWS5aLUK+mSt0EBCSyCIM0by0ABcyZ5p++CUnY3tEHL1YjvL9i6ucdEXc VGAd9nq9hqqqZZP361cJTsEvoTnUKrFwlWasDr98Tjiug/2pUKdBdnFoFb98j3exCAV5 7IIA== X-Gm-Message-State: AOJu0YwqvQqc771zoI6S7fKYWchuV0UAM7H5oT89sJA1YJDQd546mIEU y0cTbvkmRCeR9Eb1m2M3FOd5Nolli1F1xaG2jAiW8gHjSXgW7iSB1W4hoV4X5H+s X-Gm-Gg: Acq92OGmnyWDNmJH5MuhjFHKfXhBczl+CUSdyqImODMzDl3Ui/zzVLZZcn1SHvp3kwT r9qbStttVMm1JswFM11PbncKB/utTdpXzxRGuN2ow1IeU+Fai3fSMJJhttB7HGpdWrF159dUV+N N6jxj5bU+JI0SpCL3eVdVvQA2L4qpF0YnbFovAmk0MXKrXym62VO4rh6OkLpObQQLk8idPtwH6v 2qA1cCTDY2l9zodyLMJ0R5HPz6pW8UE7D3yo9DUvbGnt7u3THKMVyxgMdrlv5NHTIyaQAI+UsQy vQVcwj/7TMmnykGJaP2PdvAkX8kLMjm+YsoBEY++TwHALbJQaVDnsaditFaqwXW0/YfpAVOKtK7 hBeF2EPCnDNS3gIHmC7XKp1huhEf/RvSOhx8etget3XgONbPDMshzqaZayx2Li0TSK3rb5XvnQR vnqOZQmM7l+OPtBMKhnC1wxtOOlDwPZYk= X-Received: by 2002:a05:7022:301:b0:12a:6d05:3938 with SMTP id a92af1059eb24-134ffc6a83fmr2842716c88.7.1778879695574; Fri, 15 May 2026 14:14:55 -0700 (PDT) Received: from mimas.lan ([2603:8000:df01:38f7:a6bb:6dff:fecf:e71a]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-134cb5b3c20sm11525407c88.0.2026.05.15.14.14.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 14:14:55 -0700 (PDT) From: Ross Philipson To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org, iommu@lists.linux.dev Cc: ross.philipson@gmail.com, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com, ardb@kernel.org, mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, luto@amacapital.net, nivedita@alum.mit.edu, herbert@gondor.apana.org.au, davem@davemloft.net, corbet@lwn.net, ebiederm@xmission.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, kanth.ghatraju@oracle.com, daniel.kiper@oracle.com, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v16 15/38] Documentation/security: Secure Launch kernel documentation Date: Fri, 15 May 2026 14:13:47 -0700 Message-ID: <20260515211410.31440-16-ross.philipson@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260515211410.31440-1-ross.philipson@gmail.com> References: <20260515211410.31440-1-ross.philipson@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Daniel P. Smith" Introduce documentation for the Linux Secure Launch feature. Co-developed-by: Ross Philipson Signed-off-by: Daniel P. Smith Signed-off-by: Ross Philipson --- Documentation/arch/x86/boot.rst | 8 + Documentation/security/index.rst | 1 + .../security/launch-integrity/index.rst | 9 + .../launch-integrity/secure_launch.rst | 681 ++++++++++++++++++ 4 files changed, 699 insertions(+) create mode 100644 Documentation/security/launch-integrity/index.rst create mode 100644 Documentation/security/launch-integrity/secure_launch.rst diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst index dca3875a2435..eb53da9dcbbf 100644 --- a/Documentation/arch/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -482,6 +482,14 @@ Protocol: 2.00+ - If 1, KASLR enabled. - If 0, KASLR disabled. + Bit 2 (kernel internal): SLAUNCH_FLAG + + - Used internally by the setup kernel to communicate + Secure Launch status to the kernel proper. + + - If 1, Secure Launch enabled. + - If 0, Secure Launch disabled. + Bit 5 (write): QUIET_FLAG - If 0, print early messages. diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst index 3e0a7114a862..f89741271ed0 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -20,3 +20,4 @@ Security Documentation landlock secrets/index ipe + launch-integrity/index diff --git a/Documentation/security/launch-integrity/index.rst b/Documentation/security/launch-integrity/index.rst new file mode 100644 index 000000000000..fb9f63f01056 --- /dev/null +++ b/Documentation/security/launch-integrity/index.rst @@ -0,0 +1,9 @@ +===================================== +System Launch Integrity documentation +===================================== + +.. toctree:: + :maxdepth: 3 + + secure_launch + diff --git a/Documentation/security/launch-integrity/secure_launch.rst b/Documentation/security/launch-integrity/secure_launch.rst new file mode 100644 index 000000000000..b4c61fdceaf0 --- /dev/null +++ b/Documentation/security/launch-integrity/secure_launch.rst @@ -0,0 +1,681 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright (c) 2019-2026 Daniel P. Smith + +====================== +Secure Launch Overview +====================== + +:Author: Daniel P. Smith +:Date: February 2026 + +Overview +======== + +The TrenchBoot project initiated development of the Secure Launch kernel +feature to establish a generalized framework for dynamic root-of-trust +measurement (DRTM). The effort addresses two core objectives: (1) exposing the +platform-specific launch protocols (e.g., Intel TXT, AMD SKINIT, Arm DRTM, and +potentially OpenPOWER) directly to the Linux kernel, and (2) enabling the +kernel to act as the dynamic launch initiator. This design provides the +necessary foundation for the Linux kernel to support a broad range of dynamic +launch use cases without platform-specific user-space intermediaries. + +.. note:: + 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. + +Goals +===== + +The primary use case initially targeted by the TrenchBoot project is the +ability for the Linux kernel to be launched via a dynamic launch during the +early boot sequence. In this scenario, the dynamic launch is initiated by a +bootloader that has been extended with Secure Launch support. The first +bootloader targeted was GRUB2. + +An essential part of establishing measurement-based launch integrity is +ensuring that all components intended for execution (kernel image, initrd, +etc.) and all configuration data that will affect kernel execution (command +line, boot parameters, etc.) are measured prior to execution. These +measurements are then stored securely using the Trusted Platform Module (TPM). + +Both Intel TXT and AMD dynamic launch implementations use the TPM for this +purpose. The architecture is designed so that a dynamic launch unlocks a +specific set of Platform Configuration Registers (PCRs) reserved for DRTM +(Dynamic Root of Trust for Measurement) measurements. These registers are known +as the **DRTM PCRs** (PCRs 17-22). + +Further details on the hardware mechanisms are documented in Intel's Trusted +Execution Technology specification for the ``GETSEC`` instruction and AMD's +documentation for the ``SKINIT`` instruction. See the `Resources` section for +references. + +.. note:: + Currently, only Intel TXT is supported in this first release of the Secure + Launch feature. AMD/Hygon SKINIT and Arm support will be added in a + subsequent release. + +To enable the Linux kernel to be launched via the Intel ``GETSEC`` instruction, +a Secure Launch entry point is built into the mainline kernel. This entry point +is responsible for handling the specific processor state that the dynamic +launch process leaves the Bootstrap Processor (BSP) in. + +The Secure Launch entry point performs the earliest possible measurements of +all components and data that the kernel will consume (kernel image, initrd, +command line, boot parameters, etc.). Both this entry point code and subsequent +kernel initialization code must also correctly handle the specific state that +the dynamic launch leaves the Application Processors (APs) in. + +Design Decisions +================ + +Several design decisions were made during the development of the Secure Launch +feature. The primary guiding principle was to minimize the modifications to the +existing boot path of the kernel as little as possible. + +The following illustrate how the implementation followed these principle: + + - All the entry point code necessary to properly configure the system post + launch is found in sl_stub.S in the kernel image. This code + validates the state of the system, restores necessary system operating + configurations and properly handles post launch CPU states. + - Support is introduced in the SMP boot code to properly wake the APs. This + is required due to the unique state the dynamic launch leaves the APs in + (i.e. they cannot be woken with the standard INIT-SIPI sequence). + - Final setup for the Secure Launch kernel is done in a separate Secure Launch + module that is loaded via a late initcall. This code is responsible for + setting up the securityfs interface to allow access to the TPM event log and + public TXT registers. + - On the reboot and kexec paths, calls are made to a function to finalize the + state of the Secure Launch kernel. + +Basic Boot Flow +=============== + +Outlined here is a summary of the boot flow for Secure Launch. A more detailed +review of the Secure Launch process can be found in the Secure Launch +Specification (a link is in the `Resources`_ section). + +Pre-launch: *Phase where the environment is prepared and configured to initiate +the secure launch by the boot chain.* + + - The SLRT is initialized, and dl_stub is placed in memory. + - Load the kernel, initrd and ACM [4]_ into memory. + - Set up the TXT heap and page tables describing the MLE [1]_ per the + specification. + - If non-UEFI platform, SLRT is registered in boot params and dl_stub is + called from the legacy setup kernel. + - If UEFI platform, SLRT registered with UEFI and kernel efi-stub support calls + dl_stub after executing EBS. + - The dl_stub will prepare the CPU and the TPM for the launch. + - The secure launch is then initiated with the GETSET[SENTER] instruction. + +Post-launch: *Phase where control is passed from the ACM to the MLE and the secure +kernel begins execution.* + + - 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. + - APs are left in an optimized (MONITOR/MWAIT) wait state. + - SL main does validation of buffers and memory locations. It sets + the boot parameter loadflag value SLAUNCH_FLAG to inform the main + kernel that a Secure Launch was done. + - SL main locates the TPM event log and writes the measurements of + configuration and module information into it. + - The SMP bring up code is modified to wake the waiting APs via the monitor + address. + - SL platform module is registered as a late initcall module. + - SL platform module initializes the securityfs interface to allow + access 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). + +PCR Usage +========= + +The TCG DRTM architecture defines three PCRs for dynamic root of trust +measurement: + +- PCR.Details (PCR 17) +- PCR.Authorities (PCR 18) +- PCR.DLME_Authority (PCR 19) + +Further details on the semantics of the Details and Authorities PCRs are +available in the TCG DRTM Architecture specification. + +The Linux kernel's Secure Launch implementation adheres to the TrenchBoot +Secure Launch Specification. It utilizes a measurement policy stored in the +`Secure Launch Resource Table` (``SLRT``) to determine both what to measure and +into which PCR each measurement should be extended. + +This policy makes it possible for the kernel to store its own DRTM measurements +(such as an external initrd image) into **PCR.DLME_Detail** (PCR 20). When +combined with storing user authority information into **PCR.DLME_Authority** +(PCR 19), it enables sealing and attestation across different combinations of +platform and user details/authorities. + +An example of this approach was presented in the FOSDEM 2021 talk titled +"Secure Upgrades with DRTM". + +Configuration +============= + +The settings to enable Secure Launch using Kconfig are under:: + + "Processor type and features" --> "Secure Launch support" + +A kernel with this option enabled can still be booted using other supported +methods. + +To reduce the Trusted Computing Base (TCB) of the MLE [1]_, the build +configuration should be pared down as narrowly as one's use case allows. +Fewer drivers (less active hardware) and features reduce the attack surface. +As an example in the extreme, the MLE could only have local disk access with no +other hardware supports except optional network access for remote attestation. + +It is also desirable, if possible, to embed the initrd used with the MLE kernel +image to reduce complexity. + +The following are important configuration necessities to always consider: + +IOMMU Configuration +------------------- + +When doing a Secure Launch, the IOMMU should always be enabled and the drivers +loaded. However, IOMMU passthrough mode should never be used. This leaves the +MLE completely exposed to DMA after the PMRs [2]_ are disabled. The current +default mode is to use IOMMU in lazy translated mode, but strict translated +mode, is the preferred IOMMU mode and this should be selected in the build +configuration:: + + "Device Drivers" --> + "IOMMU Hardware Support" --> + "IOMMU default domain type" --> + "(X) Translated - Strict" + +In addition, the Intel IOMMU should be on by default. The following sets this as the +default in the build configuration:: + + "Device Drivers" --> + "IOMMU Hardware Support" --> + "Support for Intel IOMMU using DMA Remapping Devices [*]" + +and:: + + "Device Drivers" --> + "IOMMU Hardware Support" --> + "Support for Intel IOMMU using DMA Remapping Devices [*]" --> + "Enable Intel DMA Remapping Devices by default [*]" + +It is recommended that no other command line options should be set to override +the defaults above. If there is a desire to run an alternate configuration, +then that configuration should be evaluated for what benefits might +be gained against the risks for DMA attacks to which the kernel is likely +going to be exposed. + +Secure Launch Resource Table +============================ + +The Secure Launch Resource Table (SLRT) is a platform-agnostic, standard format +for providing information for the pre-launch environment and to pass +information to the post-launch environment. The table is populated by one or +more bootloaders in the boot chain and used by Secure Launch on how to set up +the environment during post-launch. The details for the SLRT are documented +in the TrenchBoot Secure Launch Specification [3]_. + +Intel TXT Interface +=================== + +The primary interfaces between the various components in TXT are the TXT MMIO +registers and the TXT heap. The MMIO register banks are described in Appendix B +of the TXT MLE [1]_ Development Guide. + +The TXT heap is described in Appendix C of the TXT MLE [1]_ Development +Guide. Most of the TXT heap is predefined in the specification. The heap is +initialized by firmware and the pre-launch environment and is subsequently used +by the SINIT ACM. One section, called the OS to MLE Data Table, is reserved for +software to define. This table is set up per the recommendation detailed in +Appendix B of the TrenchBoot Secure Launch Specification:: + + /* + * Secure Launch defined OS/MLE TXT Heap table + */ + struct txt_os_mle_data { + u32 version; + u32 reserved; + u64 slrt; + u64 txt_info; + u32 ap_wake_block; + u32 ap_wake_block_size; + u8 mle_scratch[64]; + } __packed; + +Description of structure: + +===================== ======================================================================== +Field Use +===================== ======================================================================== +version Structure version, current value 1 +slrt Physical address of the Secure Launch Resource Table +txt_info Pointer into the SLRT for easily locating TXT specific table +ap_wake_block Physical address of the block of memory for parking APs after a launch +ap_wake_block_size Size of the AP wake block +mle_scratch Scratch area used post-launch by the MLE kernel. Fields: + + - SL_SCRATCH_AP_EBX area to share %ebx base pointer among CPUs + - SL_SCRATCH_AP_JMP_OFFSET offset to abs. ljmp fixup location for APs + - SL_SCRATCH_AP_STACKS_OFFSET offset to AP startup stacks in wake block +===================== ======================================================================== + +Error Codes +=========== + +The TXT specification defines the layout for TXT 32 bit error code values. +The bit encodings indicate where the error originated (e.g. with the CPU, +in the SINIT ACM, in software). The error is written to a sticky TXT +register that persists across resets called TXT.ERRORCODE (see the TXT +MLE Development Guide). The errors defined by the Secure Launch feature are +those generated in the MLE software. They have the format:: + + 0xc0008XXX + +The low 12 bits are free for defining the following Secure Launch specific +error codes. + +0xc0008001: SL_ERROR_GENERIC +---------------------------- + +Description: + +Generic catch all error. Currently unused. + +0xc0008002: SL_ERROR_TPM_INIT +----------------------------- + +Description: + +The Secure Launch code failed to get access to the TPM hardware interface. +This is most likely due to misconfigured hardware or kernel. Ensure the TPM +chip is enabled, and the kernel TPM support is built in (it should not be built +as a module). + +0xc0008003: SL_ERROR_TPM_INVALID_LOG20 +-------------------------------------- + +Description: + +Either the Secure Launch code failed to find a valid event log descriptor for a +version 2.0 TPM, or the event log descriptor is malformed. Usually this +indicates incompatible versions of the pre-launch environment and the +MLE kernel. The pre-launch environment and the kernel share a structure in the +TXT heap and if this structure (the OS-MLE table) is mismatched, this error is +common. This TXT heap area is set up by the pre-launch environment, so the +issue may originate there. It could also be the sign of an attempted attack. + +0xc0008004: SL_ERROR_TPM_LOGGING_FAILED +--------------------------------------- + +Description: + +There was a failed attempt to write a TPM event to the event log early in the +Secure Launch process. This is likely the result of a malformed TPM event log +buffer. Formatting of the event log buffer information is done by the +pre-launch environment, so the issue most likely originates there. + +0xc0008005: SL_ERROR_REGION_STRADDLE_4GB +---------------------------------------- + +Description: + +During early validation, a buffer or region was found to straddle the 4Gb +boundary. Because of the way TXT provides DMA memory protection, this is an unsafe +configuration and is flagged as an error. This is most likely a configuration +issue in the pre-launch environment. It could also be the sign of an attempted +attack. + +0xc0008006: SL_ERROR_TPM_EXTEND +------------------------------- + +Description: + +There was a failed attempt to extend a TPM PCR in the Secure Launch platform +module. This is most likely to due to misconfigured hardware or kernel. Ensure +the TPM chip is enabled, and the kernel TPM support is built in (it should not +be built as a module). + +0xc0008007: SL_ERROR_MTRR_INV_VCNT +---------------------------------- + +Description: + +During early Secure Launch validation, an invalid variable MTRR count was +found. The pre-launch environment passes several MSR values to the MLE to +restore including the MTRRs. The values are restored by the Secure Launch early +entry point code. After measuring the values supplied by the pre-launch +environment, a discrepancy was found, validating the values. It could be the +sign of an attempted attack. + +0xc0008008: SL_ERROR_MTRR_INV_DEF_TYPE +-------------------------------------- + +Description: + +During early Secure Launch validation, an invalid default MTRR type was found. +See SL_ERROR_MTRR_INV_VCNT for more details. + +0xc0008009: SL_ERROR_MTRR_INV_BASE +---------------------------------- + +Description: + +During early Secure Launch validation, an invalid variable MTRR base value was +found. See SL_ERROR_MTRR_INV_VCNT for more details. + +0xc000800a: SL_ERROR_MTRR_INV_MASK +---------------------------------- + +Description: + +During early Secure Launch validation, an invalid variable MTRR mask value was +found. See SL_ERROR_MTRR_INV_VCNT for more details. + +0xc000800b: SL_ERROR_MSR_INV_MISC_EN +------------------------------------ + +Description: + +During early Secure Launch validation, an invalid miscellaneous enable MSR +value was found. See SL_ERROR_MTRR_INV_VCNT for more details. + +0xc000800c: SL_ERROR_INV_AP_INTERRUPT +------------------------------------- + +Description: + +The application processors (APs) wait to be woken up by the SMP initialization +code. The only interrupt that they expect is an NMI; all other interrupts +should be masked. If an AP gets an interrupt other than an NMI, it will +cause this error. This error is very unlikely to occur. + +0xc000800d: SL_ERROR_INTEGER_OVERFLOW +------------------------------------- + +Description: + +A buffer base and size passed to the MLE caused an integer overflow when +added together. This is most likely a configuration issue in the pre-launch +environment. It could also be the sign of an attempted attack. + +0xc000800e: SL_ERROR_HEAP_WALK +------------------------------ + +Description: + +An error occurred in TXT heap walking code. The underlying issue is a failure to +early_memremap() portions of the heap, most likely due to a resource shortage. + +0xc000800f: SL_ERROR_HEAP_MAP +----------------------------- + +Description: + +This error is essentially the same as SL_ERROR_HEAP_WALK, but occurred during the +actual early_memremap() operation. + +0xc0008010: SL_ERROR_REGION_ABOVE_4GB +------------------------------------- + +Description: + +A memory region used by the MLE is above 4Gb. In general, this is not a problem +because memory > 4Gb can be protected from DMA. There are certain buffers that +should never be above 4Gb, and one of these caused the violation. This is most +likely a configuration issue in the pre-launch environment. It could also be +the sign of an attempted attack. + +0xc0008011: SL_ERROR_HEAP_INVALID_DMAR +-------------------------------------- + +Description: + +The backup copy of the ACPI DMAR table, which is expected to be in the +TXT heap, could not be found. This is due to a bug in the platform's ACM module +or in firmware. + +0xc0008012: SL_ERROR_HEAP_DMAR_SIZE +----------------------------------- + +Description: + +The backup copy of the ACPI DMAR table in the TXT heap is too large to be stored +for later usage. This error is very unlikely to occur since the area reserved +for the copy is far larger than the DMAR should be. + +0xc0008013: SL_ERROR_HEAP_DMAR_MAP +---------------------------------- + +Description: + +The backup copy of the ACPI DMAR table in the TXT heap could not be mapped. The +underlying issue is a failure to early_memremap() the DMAR table, most likely +due to a resource shortage. + +0xc0008014: SL_ERROR_HI_PMR_BASE +-------------------------------- + +Description: + +On a system with more than 4Gb of RAM, the high PMR [2]_ base address should be +set to 4Gb. This error is due to that not being the case. This PMR value is set +by the pre-launch environment, so the issue most likely originates there. It +could also be the sign of an attempted attack. + +0xc0008015: SL_ERROR_HI_PMR_SIZE +-------------------------------- + +Description: + +On a system with more than 4Gb of RAM, the high PMR [2]_ size should be set to +cover all RAM > 4Gb. This error is due to that not being the case. This PMR +value is set by the pre-launch environment, so the issue most likely originates +there. It could also be the sign of an attempted attack. + +0xc0008016: SL_ERROR_LO_PMR_BASE +-------------------------------- + +Description: + +The low PMR [2]_ base should always be set to address zero. This error is due +to that not being the case. This PMR value is set by the pre-launch environment +so the issue most likely originates there. It could also be the sign of an +attempted attack. + +0xc0008017: SL_ERROR_LO_PMR_MLE +------------------------------- + +Description: + +This error indicates the MLE image is not covered by the low PMR [2]_ range. +The PMR values are set by the pre-launch environment, so the issue most likely +originates there. It could also be the sign of an attempted attack. + +0xc0008018: SL_ERROR_INITRD_TOO_BIG +----------------------------------- + +Description: + +The external initrd provided is larger than 4Gb. This is not a valid +configuration for Secure Launch due to managing DMA protection. + +0xc0008019: SL_ERROR_HEAP_ZERO_OFFSET +------------------------------------- + +Description: + +During a TXT heap walk, an invalid/zero next table offset value was found. This +indicates the TXT heap is malformed. The TXT heap is initialized by the +pre-launch environment, so the issue most likely originates there. It could +also be a sign of an attempted attack. In addition, ACM is also responsible for +manipulating parts of the TXT heap, so the issue could be due to a bug in the +platform's ACM module. + +0xc000801a: SL_ERROR_WAKE_BLOCK_TOO_SMALL +----------------------------------------- + +Description: + +The AP wake block buffer passed to the MLE via the OS-MLE TXT heap table is not +large enough. This value is set by the pre-launch environment, so the issue +most likely originates there. It also could be the sign of an attempted attack. + +0xc000801b: SL_ERROR_MLE_BUFFER_OVERLAP +--------------------------------------- + +Description: + +One of the buffers passed to the MLE via the OS-MLE TXT heap table overlaps +with the MLE image in memory. This value is set by the pre-launch environment +so the issue most likely originates there. It could also be the sign of an +attempted attack. + +0xc000801c: SL_ERROR_BUFFER_BEYOND_PMR +-------------------------------------- + +Description: + +One of the buffers passed to the MLE via the OS-MLE TXT heap table is not +protected by a PMR. This value is set by the pre-launch environment, so the +issue most likely originates there. It could also be the sign of an attempted +attack. + +0xc000801d: SL_ERROR_OS_SINIT_BAD_VERSION +----------------------------------------- + +Description: + +The version of the OS-SINIT TXT heap table is bad. It must be 6 or greater. +This value is set by the pre-launch environment, so the issue most likely +originates there. It could also be the sign of an attempted attack. It is also +possible though very unlikely that the platform is so old that the ACM being +used requires an unsupported version. + +0xc000801e: SL_ERROR_EVENTLOG_MAP +--------------------------------- + +Description: + +An error occurred in the Secure Launch module while mapping the TPM event log. +The underlying issue is memremap() failure, most likely due to a resource +shortage. + +0xc000801f: SL_ERROR_TPM_INVALID_ALGS +------------------------------------- + +Description: + +The TPM 2.0 event log reports either no hashing algorithms, invalid algorithm ID +or an algorithm size larger than the max size recognized by the TPM support code. + +0xc0008020: SL_ERROR_TPM_EVENT_COUNT +------------------------------------ + +Description: + +The TPM 2.0 event log contains an event with a digest count that is not equal +to the algorithm count of the overall log. This is an invalid configuration +that could indicate either a bug or a possible attack. + +0xc0008021: SL_ERROR_TPM_INVALID_EVENT +-------------------------------------- + +Description: + +An invalid/malformed event was found in the TPM event log while reading it. +Since only trusted entities are supposed to be writing the event log, this +would indicate either a bug or a possible attack. + +0xc0008022: SL_ERROR_INVALID_SLRT +--------------------------------- + +Description: + +The Secure Launch Resource Table is invalid or malformed and is unusable. This +implies the pre-launch code did not properly set up the SLRT. + +0xc0008023: SL_ERROR_SLRT_MISSING_ENTRY +--------------------------------------- + +Description: + +The Secure Launch Resource Table is missing a required entry within it. This +implies the pre-launch code did not properly set up the SLRT. + +0xc0008024: SL_ERROR_SLRT_MAP +----------------------------- + +Description: + +An error occurred in the Secure Launch module while mapping the Secure Launch +Resource table. The underlying issue is memremap() failure, most likely due to +a resource shortage. + + +Resources +========= + +The TrenchBoot project: + +https://trenchboot.org + +Secure Launch Specification: + +https://trenchboot.org/specifications/Secure_Launch/ + +Trusted Computing Group's D-RTM Architecture: + +https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture_v1-0_Published_06172013.pdf + +TXT documentation in the Intel TXT MLE Development Guide: + +https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf + +TXT instructions documentation in the Intel SDM Instruction Set volume: + +https://software.intel.com/en-us/articles/intel-sdm + +AMD SKINIT documentation in the System Programming manual: + +https://www.amd.com/system/files/TechDocs/24593.pdf + +GRUB Secure Launch support: + +https://github.com/TrenchBoot/grub/tree/grub-sl-fc-38-dlstub + +FOSDEM 2021: Secure Upgrades with DRTM + +https://archive.fosdem.org/2021/schedule/event/firmware_suwd/ + +.. [1] + MLE: Measured Launch Environment is the binary runtime that is measured and + then run by the TXT SINIT ACM. The TXT MLE Development Guide describes the + requirements for the MLE in detail. + +.. [2] + PMR: Intel VTd has a feature in the IOMMU called Protected Memory Registers. + There are two of these registers and they allow all DMA to be blocked + to large areas of memory. The low PMR can cover all memory below 4Gb on 2Mb + boundaries. The high PMR can cover all RAM on the system, again on 2Mb + boundaries. This feature is used during a Secure Launch by TXT. + +.. [3] + Secure Launch Specification: https://trenchboot.org/specifications/Secure_Launch/ + +.. [4] + ACM: Intel's Authenticated Code Module. This is the 32b bit binary blob that + is run securely by the GETSEC[SENTER] during a measured launch. It is described + in the Intel documentation on TXT and versions for various chipsets are + signed and distributed by Intel. -- 2.47.3