From patchwork Thu Dec 19 19:41:58 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852157 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F3D31BEF6C; Thu, 19 Dec 2024 19:55:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.177.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638131; cv=none; b=Oy5HfeU9yHgIwLmmQQtPCTEex8ipoIgu06QHFXSgnIqwUAGk37VV7IVdDIKPecB4j3SOcQ7JPI/i2lQ/FqoFS7D/VLAwPJySSiPobtQBY8JRhlY0AFd5sIf/lhZAjZa0O+n167rLoDpqwezVFqX1z+JCOvdo/WWsr9luhND0Dc4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638131; c=relaxed/simple; bh=6WQtfzcDD12afWGgXa15DgyNAsFjmrqk+UnRmY+Jhdg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=XxwLnzVlje+axq8kCmzX345t6x36oi9XC3vKObkGTEbOPFFyxbmf9pFYXhKAuEoPIt9UCWU2Usu4tRVZUX6XjP3Bi8MsrTgoXnnqX8kYczzGi1khqFIzNog0lpBJb2eLm4SLCDd2QiPogxrg+ce8GjZBwzk0/C16c76kfO0xdm0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=N7yAV03c; arc=none smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="N7yAV03c" Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMgLp005156; Thu, 19 Dec 2024 19:53:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=TrJlw mIa4qN8lqSzFjwVoKeNbqRLBhYWt2jKgQ0utVI=; b=N7yAV03cs1HLn4pwVOBNm vxKbmwiNx5asmkoeMXejhhnk+WntSYEmEh5fe3gTt/guImFwyhL9iMxQ8UgS+XbA iYNEzp6FjV9uF0454qxlmti79wB8bDtXCqyj6zwZaoXmVyEYNALN6UZcFV4I3Yog 9zsb7+BUgqJQRDCVMjKdLOIjoPiHAzF0G/+fNbLH8/sIz8o3t1Ngjk21VU0ehztD vhrNnYlR3q7kZoRoaGEvKuvuy6hT64XhX7yqsfwxefd3L1sOQFGjBVsuecsbesZr 1yxdyXl5A4Z3V6k0oMlIM4y7y2r6EmoO04ekEbs1ERKclV+DoMkOtmbsB/pfmjrD Q== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h0t2ksan-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:53:39 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJJkqEg035387; Thu, 19 Dec 2024 19:53:38 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbngwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:53:38 +0000 Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJrbXk032931; Thu, 19 Dec 2024 19:53:37 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbngvs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:53:37 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 01/19] Documentation/x86: Secure Launch kernel documentation Date: Thu, 19 Dec 2024 11:41:58 -0800 Message-Id: <20241219194216.152839-2-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 spamscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-ORIG-GUID: MSQzQLWyl4hihQUHuj53Ct_ORS0ow62g X-Proofpoint-GUID: MSQzQLWyl4hihQUHuj53Ct_ORS0ow62g From: "Daniel P. Smith" Introduce background, overview and configuration/ABI information for the Secure Launch kernel feature. Signed-off-by: Daniel P. Smith Signed-off-by: Ross Philipson Reviewed-by: Bagas Sanjaya --- Documentation/security/index.rst | 1 + .../security/launch-integrity/index.rst | 11 + .../security/launch-integrity/principles.rst | 317 ++++++++++ .../secure_launch_details.rst | 587 ++++++++++++++++++ .../secure_launch_overview.rst | 252 ++++++++ 5 files changed, 1168 insertions(+) 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 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..838328186dd2 --- /dev/null +++ b/Documentation/security/launch-integrity/index.rst @@ -0,0 +1,11 @@ +===================================== +System Launch Integrity documentation +===================================== + +.. toctree:: + :maxdepth: 1 + + principles + secure_launch_overview + secure_launch_details + diff --git a/Documentation/security/launch-integrity/principles.rst b/Documentation/security/launch-integrity/principles.rst new file mode 100644 index 000000000000..a0553d1d93c2 --- /dev/null +++ b/Documentation/security/launch-integrity/principles.rst @@ -0,0 +1,317 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright (c) 2019-2024 Daniel P. Smith + +======================= +System Launch Integrity +======================= + +:Author: Daniel P. Smith +:Date: August 2024 + +This document serves to establish a common understanding of what a system +launch is, the integrity concern for system launch, and why using a Root of Trust +(RoT) from a Dynamic Launch may be desirable. Throughout this document, +terminology from the Trusted Computing Group (TCG) and National Institute for +Standards and Technology (NIST) is used to ensure that vendor natural language is +used to describe and reference security-related concepts. + +System Launch +============= + +There is a tendency to only consider the classical power-on boot as the only +means to launch an Operating System (OS) on a computer system. In fact, most +modern processors support two system launch methods. To provide clarity, +it is important to establish a common definition of a system launch: during +a single power life cycle of a system, a system launch consists of an initialization +event, typically in hardware, that is followed by an executing software payload +that takes the system from the initialized state to a running state. Driven by +the Trusted Computing Group (TCG) architecture, modern processors are able to +support two methods of system launch. These two methods of system launch are known +as Static Launch and Dynamic Launch. + +Static Launch +------------- + +Static launch is the system launch associated with the power cycle of the CPU. +Thus, static launch refers to the classical power-on boot where the +initialization event is the release of the CPU from reset and the system +firmware is the software payload that brings the system up to a running state. +Since static launch is the system launch associated with the beginning of the +power lifecycle of a system, it is therefore a fixed, one-time system launch. +It is because of this that static launch is referred to and thought of as being +"static". + +Dynamic Launch +-------------- + +Modern CPUs architectures provides a mechanism to re-initialize the system to a +"known good" state without requiring a power event. This re-initialization +event is the event for a dynamic launch and is referred to as the Dynamic +Launch Event (DLE). The DLE functions by accepting a software payload, referred +to as the Dynamic Configuration Environment (DCE), that execution is handed to +after the DLE is invoked. The DCE is responsible for bringing the system back +to a running state. Since the dynamic launch is not tied to a power event like +the static launch, this enables a dynamic launch to be initiated at any time +and multiple times during a single power life cycle. This dynamism is the +reasoning behind referring to this system launch as "dynamic". + +Because a dynamic launch can be conducted at any time during a single power +life cycle, they are classified into one of two types: an early launch or a +late launch. + +:Early Launch: When a dynamic launch is used as a transition from a static + launch chain to the final Operating System. + +:Late Launch: The usage of a dynamic launch by an executing Operating System to + transition to a "known good" state to perform one or more operations, e.g. to + launch into a new Operating System. + +System Integrity +================ + +A computer system can be considered a collection of mechanisms that work +together to produce a result. The assurance that the mechanisms are functioning +correctly and producing the expected result is the integrity of the system. To +ensure a system's integrity, there is a subset of these mechanisms, commonly +referred to as security mechanisms, that is present to help ensure the system +produces the expected result or at least detects the potential of an unexpected +result. Since the security mechanisms are relied upon to ensue the integrity of +the system, these mechanisms are trusted. Upon inspection, these security +mechanisms each have a set of properties and these properties can be evaluated +to determine how susceptible a mechanism might be to failure. This assessment is +referred to as the Strength of Mechanism, which allows the trustworthiness of +that mechanism to be quantified. + +For software systems, there are two system states for which the integrity is +critical: when the software is loaded into memory and when the software is +executing on the hardware. Ensuring that the expected software is loaded into +memory is referred to as load-time integrity while ensuring that the software +executing is the expected software is the runtime integrity of that software. + +Load-time Integrity +------------------- + +It is critical to understand what load-time integrity establishes about a +system and what is assumed, i.e. what is being trusted. Load-time integrity is +when a trusted entity, i.e. an entity with an assumed integrity, takes an +action to assess an entity being loaded into memory before it is used. A +variety of mechanisms may be used to conduct the assessment, each with +different properties. A particular property is whether the mechanism creates an +evidence of the assessment. Often either cryptographic signature checking or +hashing are the common assessment operations used. + +A signature checking assessment functions by requiring a representation of the +accepted authorities and uses those representations to assess if the entity has +been signed by an accepted authority. The benefit to this process is that +assessment process includes an adjudication of the assessment. The drawbacks +are that 1) the adjudication is susceptible to tampering by the Trusted +Computing Base (TCB), 2) there is no evidence to assert that an untampered +adjudication was completed, and 3) the system must be an active participant in +the key management infrastructure. + +A cryptographic hashing assessment does not adjudicate the assessment, but +instead generates evidence of the assessment to be adjudicated independently. +The benefits to this approach is that the assessment may be simple such that it +may be implemented in an immutable mechanism, e.g. in hardware. Additionally, +it is possible for the adjudication to be conducted where it cannot be tampered +with by the TCB. The drawback is that a compromised environment will be allowed +to execute until an adjudication can be completed. + +Ultimately, load-time integrity provides confidence that the correct entity was +loaded and in the absence of a run-time integrity mechanism assumes, i.e. +trusts, that the entity will never become corrupted. + +Runtime Integrity +----------------- + +Runtime integrity in the general sense is when a trusted entity makes an +assessment of an entity at any point in time during the assessed entity's +execution. A more concrete explanation is the taking of an integrity assessment +of an active process executing on the system at any point during the process' +execution. Often the load-time integrity of an operating system's user-space, +i.e. the operating environment, is confused with the runtime integrity of the +system, since it is an integrity assessment of the "runtime" software. The +reality is that actual runtime integrity is a very difficult problem and thus +not very many solutions are public and/or available. One example of a runtime +integrity solution would be Johns Hopkins Advanced Physics Laboratory's (APL) +Linux Kernel Integrity Module (LKIM). + +Trust Chains +============ + +Building upon the understanding of security mechanisms to establish load-time +integrity of an entity, it is possible to chain together load-time integrity +assessments to establish the integrity of the whole system. This process is +known as transitive trust and provides the concept of building a chain of +load-time integrity assessments, commonly referred to as a trust chain. These +assessments may be used to adjudicate the load-time integrity of the whole +system. This trust chain is started by a trusted entity that does the first +assessment. This first entity is referred to as the Root of Trust(RoT) with the +entities name being derived from the mechanism used for the assessment, i.e. +RoT for Verification (RTV) and RoT for Measurement (RTM). + +A trust chain is itself a mechanism, specifically a mechanism of mechanisms, +and therefore it also has a Strength of Mechanism. The factors that contribute +to the strength of a trust chain are: + + - The strength of the chain's RoT + - The strength of each member of the trust chain + - The length, i.e. the number of members, of the chain + +Therefore, the strongest trust chains should start with a strong RoT and should +consist of members being of low complexity and minimize the number of members +participating. In a more colloquial sense, a trust chain is only as strong as its +weakest link, thus more links increase the probability of a weak link. + +Dynamic Launch Components +========================= + +The TCG architecture for dynamic launch is composed of a component series +used to set up and then carry out the launch. These components work together to +construct an RTM trust chain that is rooted in the dynamic launch and thus commonly +referred to as the Dynamic Root of Trust for Measurement (DRTM) chain. + +What follows is a brief explanation of each component in execution order. A +subset of these components are what establishes the dynamic launch's trust +chain. + +Dynamic Configuration Environment Preamble +------------------------------------------ + +The Dynamic Configuration Environment (DCE) Preamble is responsible for setting +up the system environment in preparation for a dynamic launch. The DCE Preamble +is not a part of the DRTM trust chain. + +Dynamic Launch Event +-------------------- + +The dynamic launch event is the event, typically a CPU instruction, that +triggers the system's dynamic launch mechanism to begin the launch process. The +dynamic launch mechanism is also the RoT for the DRTM trust chain. + +Dynamic Configuration Environment +--------------------------------- + +The dynamic launch mechanism may have resulted in a reset of a portion of the +system. To bring the system back to an adequate state for system software, the +dynamic launch will hand over control to the DCE. Prior to handing over this +control, the dynamic launch will measure the DCE. Once the DCE is complete, it +will proceed to measure and then execute the Dynamic Launch Measured +Environment (DLME). + +Dynamic Launch Measured Environment +----------------------------------- + +The DLME is the first system kernel to have control of the system, but may not +be the last. Depending on the usage and configuration, the DLME may be the +final/target operating system, or it may be a bootloader that will load the +final/target operating system. + +Why DRTM +======== + +It is a fact that DRTM increases the load-time integrity of the system by +providing a trust chain that has an immutable hardware RoT, uses a limited +number of small, special purpose code to establish the trust chain that starts +the target operating system. As mentioned in the Trust Chain section, these are +the main three factors in driving up the strength of a trust chain. As has been +seen with the BootHole exploit, which in fact did not affect the integrity of +DRTM solutions, the sophistication of attacks targeting system launch is at an +all-time high. There is no reason a system should not employ every available +hardware integrity measure. This is the crux of a defense-in-depth +approach to system security. In the past, the now closed SMI gap was often +pointed to as invalidating DRTM, which in fact was nothing but a straw man +argument. As has continued to be demonstrated, if/when SMM is corrupted, it can +always circumvent all load-time integrity (SRTM and DRTM) because it is a +run-time integrity problem. Regardless, Intel and AMD have both deployed +runtime integrity for SMI and SMM which is tied directly to DRTM such that this +perceived deficiency is now non-existent and the world is moving forward with +an expectation that DRTM must be present. + +Glossary +======== + +.. glossary:: + integrity + Guarding against improper information modification or destruction, and + includes ensuring information non-repudiation and authenticity. + + - NIST Glossary - https://csrc.nist.gov/glossary + + mechanism + A process or system that is used to produce a particular result. + + - NIST Special Publication 800-160 (VOLUME 1 ) - https://doi.org/10.6028/NIST.SP.800-160v1r1 + + risk + A measure of the extent to which an entity is threatened by a potential + circumstance or event, and typically a function of: (i) the adverse impacts + that would arise if the circumstance or event occurs; and (ii) the + likelihood of occurrence. + + - NIST SP 800-30 Rev. 1 - https://doi.org/10.6028/NIST.SP.800-30r1 + + security mechanism + A device or function designed to provide one or more security services + usually rated in terms of strength of service and assurance of the design. + + - NIST CNSSI No. 4009 - https://www.cnss.gov/CNSS/issuances/Instructions.cfm + + Strength of Mechanism + A scale for measuring the relative strength of a security mechanism + + - NIST CNSSI No. 4009 - https://www.cnss.gov/CNSS/issuances/Instructions.cfm + + transitive trust + Also known as "Inductive Trust", in this process a Root of Trust gives a + trustworthy description of a second group of functions. Based on this + description, an interested entity can determine the trust it is to place in + this second group of functions. If the interested entity determines that + the trust level of the second group of functions is acceptable, the trust + boundary is extended from the Root of Trust to include the second group of + functions. In this case, the process can be iterated. The second group of + functions can give a trustworthy description of the third group of + functions, etc. Transitive trust is used to provide a trustworthy + description of platform characteristics, and also to prove that + non-migratable keys are in fact non-migratable. + + - TCG Glossary - https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf + + trust + The confidence one element has in another that the second element will + behave as expected` + + - NISTIR 8320A - https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8320A.pdf + + trust anchor + An authoritative entity for which trust is assumed. + + - NIST SP 800-57 Part 1 Rev. 5 - https://doi.org/10.6028/NIST.SP.800-57pt1r5 + + trusted + An element that another element relies upon to fulfill critical + requirements on its behalf. + + - NISTIR 8320A - https://doi.org/10.6028/NIST.IR.8320A + + trusted computing base (TCB) + Totality of protection mechanisms within a computer system, including + hardware, firmware, and software, the combination responsible for enforcing + a security policy. + + - NIST CNSSI No. 4009 - https://www.cnss.gov/CNSS/issuances/Instructions.cfm + + trusted computer system + A system that has the necessary security functions and assurance that the + security policy will be enforced and that can process a range of + information sensitivities (i.e. classified, controlled unclassified + information (CUI), or unclassified public information) simultaneously. + + - NIST CNSSI No. 4009 - https://www.cnss.gov/CNSS/issuances/Instructions.cfm + + trustworthiness + The attribute of a person or enterprise that provides confidence to others + of the qualifications, capabilities, and reliability of that entity to + perform specific tasks and fulfill assigned responsibilities. + + - NIST CNSSI No. 4009 - https://www.cnss.gov/CNSS/issuances/Instructions.cfm diff --git a/Documentation/security/launch-integrity/secure_launch_details.rst b/Documentation/security/launch-integrity/secure_launch_details.rst new file mode 100644 index 000000000000..5a1ee802ccad --- /dev/null +++ b/Documentation/security/launch-integrity/secure_launch_details.rst @@ -0,0 +1,587 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright (c) 2019-2024 Daniel P. Smith + +=================================== +Secure Launch Config and Interfaces +=================================== + +:Author: Daniel P. Smith +:Date: August 2024 + +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: + +KASLR Configuration +------------------- + +Due to Secure Launch hardware implementation details and how KASLR functions, +Secure Launch is not able to interoperate with KASLR at this time. Attempts to +enable KASLR in a kernel started using Secure Launch may result in crashes and +other instabilities at boot. Even in cases where Secure Launch and KASLR work +together, it is still recommended that KASLR be disabled to avoid introducing +security concerns with unprotected kernel memory. + +If possible, a kernel being used as an MLE should be built with KASLR disabled:: + + "Processor type and features" --> + "Build a relocatable kernel" --> + "Randomize the address of the kernel image (KASLR) [ ]" + +This action unsets the Kconfig value CONFIG_RANDOMIZE_BASE. + +If it is not possible to disable at build time, then it is recommended to force +KASLR to be disabled using the kernel command line when doing a Secure Launch. +The kernel parameter is as follows:: + + nokaslr + +.. note:: + Should KASLR be made capable of reading/using only the protected page + regions set up by the memory protection mechanisms used by the hardware + DRTM capability, it would then become possible to use KASLR with Secure + Launch. + +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 +===================== ======================================================================== + +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. + +====== ================ +Name: SL_ERROR_GENERIC +Value: 0xc0008001 +====== ================ + +Description: + +Generic catch all error. Currently unused. + +====== ================= +Name: SL_ERROR_TPM_INIT +Value: 0xc0008002 +====== ================= + +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). + +====== ========================== +Name: SL_ERROR_TPM_INVALID_LOG20 +Value: 0xc0008003 +====== ========================== + +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. + +====== =========================== +Name: SL_ERROR_TPM_LOGGING_FAILED +Value: 0xc0008004 +====== =========================== + +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. + +====== ============================ +Name: SL_ERROR_REGION_STRADDLE_4GB +Value: 0xc0008005 +====== ============================ + +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. + +====== =================== +Name: SL_ERROR_TPM_EXTEND +Value: 0xc0008006 +====== =================== + +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). + +====== ====================== +Name: SL_ERROR_MTRR_INV_VCNT +Value: 0xc0008007 +====== ====================== + +Description: + +During early Secure Launch validation, an invalid variable MTRR count was +found. The pre-launch environment passes a number of 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. + +====== ========================== +Name: SL_ERROR_MTRR_INV_DEF_TYPE +Value: 0xc0008008 +====== ========================== + +Description: + +During early Secure Launch validation, an invalid default MTRR type was found. +See SL_ERROR_MTRR_INV_VCNT for more details. + +====== ====================== +Name: SL_ERROR_MTRR_INV_BASE +Value: 0xc0008009 +====== ====================== + +Description: + +During early Secure Launch validation, an invalid variable MTRR base value was +found. See SL_ERROR_MTRR_INV_VCNT for more details. + +====== ====================== +Name: SL_ERROR_MTRR_INV_MASK +Value: 0xc000800a +====== ====================== + +Description: + +During early Secure Launch validation, an invalid variable MTRR mask value was +found. See SL_ERROR_MTRR_INV_VCNT for more details. + +====== ======================== +Name: SL_ERROR_MSR_INV_MISC_EN +Value: 0xc000800b +====== ======================== + +Description: + +During early Secure Launch validation, an invalid miscellaneous enable MSR +value was found. See SL_ERROR_MTRR_INV_VCNT for more details. + +====== ========================= +Name: SL_ERROR_INV_AP_INTERRUPT +Value: 0xc000800c +====== ========================= + +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. + +====== ========================= +Name: SL_ERROR_INTEGER_OVERFLOW +Value: 0xc000800d +====== ========================= + +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. + +====== ================== +Name: SL_ERROR_HEAP_WALK +Value: 0xc000800e +====== ================== + +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. + +====== ================= +Name: SL_ERROR_HEAP_MAP +Value: 0xc000800f +====== ================= + +Description: + +This error is essentially the same as SL_ERROR_HEAP_WALK, but occurred during the +actual early_memremap() operation. + +====== ========================= +Name: SL_ERROR_REGION_ABOVE_4GB +Value: 0xc0008010 +====== ========================= + +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. + +====== ========================== +Name: SL_ERROR_HEAP_INVALID_DMAR +Value: 0xc0008011 +====== ========================== + +Description: + +The backup copy of the ACPI DMAR table which is supposed to be located in the +TXT heap could not be found. This is due to a bug in the platform's ACM module +or in firmware. + +====== ======================= +Name: SL_ERROR_HEAP_DMAR_SIZE +Value: 0xc0008012 +====== ======================= + +Description: + +The backup copy of the ACPI DMAR table in the TXT heap is to 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. + +====== ====================== +Name: SL_ERROR_HEAP_DMAR_MAP +Value: 0xc0008013 +====== ====================== + +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. + +====== ==================== +Name: SL_ERROR_HI_PMR_BASE +Value: 0xc0008014 +====== ==================== + +Description: + +On a system with more than 4G of RAM, the high PMR [2]_ base address should be +set to 4G. 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. + +====== ==================== +Name: SL_ERROR_HI_PMR_SIZE +Value: 0xc0008015 +====== ==================== + +Description: + +On a system with more than 4G of RAM, the high PMR [2]_ size should be set to +cover all RAM > 4G. 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. + +====== ==================== +Name: SL_ERROR_LO_PMR_BASE +Value: 0xc0008016 +====== ==================== + +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. + +====== ==================== +Name: SL_ERROR_LO_PMR_MLE +Value: 0xc0008017 +====== ==================== + +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. + +====== ======================= +Name: SL_ERROR_INITRD_TOO_BIG +Value: 0xc0008018 +====== ======================= + +Description: + +The external initrd provided is larger than 4Gb. This is not a valid +configuration for a Secure Launch due to managing DMA protection. + +====== ========================= +Name: SL_ERROR_HEAP_ZERO_OFFSET +Value: 0xc0008019 +====== ========================= + +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. + +====== ============================= +Name: SL_ERROR_WAKE_BLOCK_TOO_SMALL +Value: 0xc000801a +====== ============================= + +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. + +====== =========================== +Name: SL_ERROR_MLE_BUFFER_OVERLAP +Value: 0xc000801b +====== =========================== + +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. + +====== ========================== +Name: SL_ERROR_BUFFER_BEYOND_PMR +Value: 0xc000801c +====== ========================== + +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. + +====== ============================= +Name: SL_ERROR_OS_SINIT_BAD_VERSION +Value: 0xc000801d +====== ============================= + +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. + +====== ===================== +Name: SL_ERROR_EVENTLOG_MAP +Value: 0xc000801e +====== ===================== + +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. + +====== ======================== +Name: SL_ERROR_TPM_INVALID_ALGS +Value: 0xc000801f +====== ======================== + +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. + +====== =========================== +Name: SL_ERROR_TPM_EVENT_COUNT +Value: 0xc0008020 +====== =========================== + +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. + +====== ========================== +Name: SL_ERROR_TPM_INVALID_EVENT +Value: 0xc0008021 +====== ========================== + +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. + +====== ===================== +Name: SL_ERROR_INVALID_SLRT +Value: 0xc0008022 +====== ===================== + +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. + +====== =========================== +Name: SL_ERROR_SLRT_MISSING_ENTRY +Value: 0xc0008023 +====== =========================== + +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. + +====== ================= +Name: SL_ERROR_SLRT_MAP +Value: 0xc0008024 +====== ================= + +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. + +.. [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/ diff --git a/Documentation/security/launch-integrity/secure_launch_overview.rst b/Documentation/security/launch-integrity/secure_launch_overview.rst new file mode 100644 index 000000000000..43ea9fa8ed80 --- /dev/null +++ b/Documentation/security/launch-integrity/secure_launch_overview.rst @@ -0,0 +1,252 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright (c) 2019-2024 Daniel P. Smith + +====================== +Secure Launch Overview +====================== + +:Author: Daniel P. Smith +:Date: August 2024 + +Overview +======== + +Prior to the start of the TrenchBoot project, the only active Open Source +project supporting dynamic launch was Intel's tboot project to support their +implementation of dynamic launch known as Intel Trusted eXecution Technology +(TXT). The approach taken by tboot was to provide an exokernel that could +handle the launch protocol implemented by the Intel provided loader, the SINIT +Authenticated Code Module (ACM [2]_), and remained in memory to manage the SMX +CPU mode that a dynamic launch would put a system. While it is not precluded +from being used for a late launch, tboot's primary use case was to be +used as an early launch solution. As a result, the TrenchBoot project started +the development of Secure Launch kernel feature to provide a more generalized +approach. The focus of the effort is twofold: first, to make the Linux +kernel directly aware of the launch protocol used by Intel, AMD/Hygon, Arm, and +potentially OpenPOWER; second, to make the Linux kernel able to +initiate a dynamic launch. It is through this approach that the Secure Launch +kernel feature creates a basis for the Linux kernel to be used in a variety of +dynamic launch use cases. + +.. 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 first use case that the TrenchBoot project focused on was the ability for +the Linux kernel to be started by a dynamic launch, in particular as part of an +early launch sequence. In this case, the dynamic launch will be initiated by +any bootloader with associated support added to it. For example, the first +targeted bootloader in this case was GRUB2. An integral part of establishing a +measurement-based launch integrity involves measuring everything that is +intended to be executed (kernel image, initrd, etc.) and everything that will +configure that kernel to execute (command line, boot params, etc.), then +storing those measurements in a protected manner. Both the Intel and AMD +dynamic launch implementations leverage the Trusted Platform Module (TPM) to +store those measurements. The TPM itself has been designed such that a dynamic +launch unlocks a specific set of Platform Configuration Registers (PCR) for +holding measurement taken during the dynamic launch. These are referred to as +the DRTM PCRs, PCRs 17-22. Further details on this process can be found in the +documentation for the GETSEC instruction provided by Intel's TXT and the SKINIT +instruction provided by AMD's AMD-V. The documentation on these technologies +can be readily found online; see the `Resources`_ section below 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 kernel to be launched by GETSEC a stub, the Secure Launch 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. Also, the Secure +Launch 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 as well. + +Design Decisions +================ + +A number of design decisions were made during the development of the Secure +Launch feature. The two primary guiding decisions were: + + - Keeping the Secure Launch code as separate from the rest of the kernel + as possible. + - Modifying the existing boot path of the kernel as little as possible. + +The following illustrate how the implementation followed these design +decisions: + + - All the entry point code necessary to properly configure the system post + launch is found in st_stub.S in the compressed kernel image. This code + validates the state of the system, restores necessary system operating + configurations and properly handles post launch CPU states. + - After the sl_stub.S is complete, it jumps directly to the unmodified + startup_32 kernel entry point. + - A single call is made to a function sl_main() prior to the main kernel + decompression step. This code performs further validation and takes the + needed DRTM measurements. + - After the call to sl_main(), the main kernel is decompressed and boots as + it normally would. + - 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 extending the measurements taken earlier into the TPM DRTM PCRs and + 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. + +The one place where Secure Launch code is mixed directly in with kernel code is +in the SMP boot code. This is due to the unique state that the dynamic launch +leaves the APs in. On Intel, this involves using a method other than the +standard INIT-SIPI sequence. + +A final note is that originally the extending of the PCRs was completed in the +Secure Launch stub when the measurements were taken. An alternative solution +had to be implemented due to the TPM maintainers objecting to the PCR +extensions being done with a minimal interface to the TPM that was an +independent implementation of the mainline kernel driver. Since the mainline +driver relies heavily on kernel interfaces not available in the compressed +kernel, it was not possible to reuse the mainline TPM driver. This resulted in +the decision to move the extension operations to the Secure Launch module in +the mainline kernel, where the TPM driver would be available. + +Basic Boot Flow +=============== + +Outlined here is a summary of the boot flow for Secure Launch. A more detailed +review of Secure Launch process can be found in the Secure Launch +Specification (a link is located 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 [2]_ into memory. + - Set up the TXT heap and page tables describing the MLE [1]_ per the + specification. + - If non-UEFI platform, dl_stub is called. + - If UEFI platforms, SLRT registered with UEFI and efi-stub called. + - Upon completion, efi-stub will call EBS followed by dl_stub. + - 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. + - For TXT, APs are left halted using MONITOR/MWAIT intructions. + - SL stub jumps to startup_32. + - 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. + - Kernel boot proceeds normally from this point. + - During early setup, slaunch_setup() runs to finish validation + and setup tasks. + - The SMP bring up code is modified to wake the waiting APs via the monitor + address. + - 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 + 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 there are three PCRs defined for usage, PCR.Details +(PCR17), PCR.Authorities (PCR18), and PCR.DLME_Authority (PCR19). For a deeper +understanding of Detail and Authorities it is recommended to review the TCG +DRTM architecture. + +To determine PCR usage, Linux Secure Launch follows the TrenchBoot Secure +Launch Specification of using a measurement policy stored in the SLRT. The +policy details what should be measured and the PCR in which to store the +measurement. The measurement policy provides the ability to select the +PCR.DLME_Detail (PCR20) PCR as the location for the DRTM components measured by +the kernel, e.g. external initrd image. This can then be combined with storing +the user authority in the PCR.DLME_Authority PCR to seal/attest to different +variations of platform details/authorities and user details/authorities. An +example of how this can be achieved was presented in the FOSDEM - 2021 talk +"Secure Upgrades with DRTM". + +SHA-1 Usage +----------- + +Secure Launch is written to be compliant with the Intel TXT Measured Launch +Developer's Guide. The MLE Guide dictates that the system can be configured to +use both the SHA-1 and SHA-2 hashing algorithms. The choice is dictated by what +hash algorithm banks firmware enabled at system start time. + +Regardless of the preference towards SHA-2, if the firmware elected to start +with the SHA-1 and SHA-2 banks active and the dynamic launch was configured to +include SHA-1, Secure Launch is obligated to record measurements for all +algorithms requested in the launch configuration. If SHA-1 can be disabled in +the firmware setup, then TXT and Secure Launch will only use the SHA-2 banks +while establishing the launch environment. + +Ultimately, the security of an RTM solution is how and what measurements are +used to assess the health of a system. If SHA-1 measurements are made but not +used, i.e. the attestation enforcement only uses SHA-2, then it has zero impact +on the security of the system. + +Finally, there are older systems with TPM 1.2 chips that only support SHA-1. If +the system integrator (whether that be the OEM, employer, distro maintainer, +system administrator, or end user) chooses to use older hardware that only has +a TPM 1.2 chip, then they are accepting the risk it creates in their solution. + +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] + 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. From patchwork Thu Dec 19 19:41:59 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852156 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E8C01BD4E5; Thu, 19 Dec 2024 19:55:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638152; cv=none; b=PJStYgaxHuQH7MVCmCLtf/JP+AZyWGsuwu2uUUlVUuMMia2HHW3416Y7VHbvbMXyXEmfzg1hvF5nbyvw4lKVMau/6S2i3cOzKzn1zZBEgsYUINz4a7lamJn4N9/9auTmcLz3b6abWslSJdd7tq5X3r0m4yG4GerSHNb6nWNTnUo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638152; c=relaxed/simple; bh=dmaclvxf9TnntMUluXb08EwHCTH4g/hWhBwJSuhJdWI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=EGoP+oHuKWWktfFbimY/B3qAQojW+hYCOEWIYjikW20AoMx9K3p4K7dWODs7fiPqfgTLWzWyE3TH8J5KeH8xNqC/ZvZsnG5LV9AkGg9i309wfO4Zdh4n4B2sn7c6foyaPceZNab8zvMUT0ILHPDJduZMDWKuccLzYLSJ8V/70ZY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=He4wFQm4; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="He4wFQm4" Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJINN2R003444; Thu, 19 Dec 2024 19:54:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=iHkSe z91kyWzaGskjIuEmyVAQSjTMQkYdSsIHKK4oeU=; b=He4wFQm4R0AQd4cMmutdc srHS4Jje2+rRGeCTEzdgw5HO9ep5KBh8lApU0EqWZ6/xtwclSU1F+9DtMCQfk1IA feNt3+Weed16EYAu/YOKMVx41SwwA/JS2hukKJZqlOAlG49HXo6MHRouBbTotBWx YWdhzdT2KG+uctT6+IY5gWpxIYLFDEWst1LdmiCeJCc/BGuKFgaUcpfnnDDBK6YK oeLmSNlDczmO8bh9+tHYWfduGn5p9bK46KynwmXhS12WxQmkVgpyvqGGo+Jl2QoR GaQ/+t94NiscgDqrNvrPvvsY1gvAglBqGWdDTrpKrS2rbwqK+qZqrMW1126NSvl4 w== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h0m0c1uk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:54:24 +0000 (GMT) Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJI2KUL032770; Thu, 19 Dec 2024 19:54:22 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fhvkvf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:54:22 +0000 Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJsLtY009143; Thu, 19 Dec 2024 19:54:21 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fhvkeq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:54:21 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 02/19] x86: Secure Launch Kconfig Date: Thu, 19 Dec 2024 11:41:59 -0800 Message-Id: <20241219194216.152839-3-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: BdejskqseAZS49t0swJrHH4Qfaq3EQZM X-Proofpoint-ORIG-GUID: BdejskqseAZS49t0swJrHH4Qfaq3EQZM Initial bits to bring in Secure Launch functionality. Add Kconfig options for compiling in/out the Secure Launch code. Signed-off-by: Ross Philipson --- arch/x86/Kconfig | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 9d7bd0ae48c4..86af03707f04 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2057,6 +2057,17 @@ config EFI_RUNTIME_MAP See also Documentation/ABI/testing/sysfs-firmware-efi-runtime-map. +config SECURE_LAUNCH + bool "Secure Launch support" + depends on X86_64 && X86_X2APIC && TCG_TIS && TCG_CRB && CRYPTO_LIB_SHA1 && CRYPTO_LIB_SHA256 + help + The Secure Launch feature allows a kernel to be loaded + directly through an Intel TXT measured launch. Intel TXT + establishes a Dynamic Root of Trust for Measurement (DRTM) + where the CPU measures the kernel image. This feature then + continues the measurement chain over kernel configuration + information and init images. + source "kernel/Kconfig.hz" config ARCH_SUPPORTS_KEXEC From patchwork Thu Dec 19 19:42:01 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852158 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3C70C1BAEF8; Thu, 19 Dec 2024 19:55:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638127; cv=none; b=OQFYj8ycMhXABgDhyRNOccSGX8HDq2+7nHZMmL7KVPVPSef+T6NG/d+oT+aEfgI0VAM8RiKzxoLvR3ETKGZYf49CcY8zGTGab8PXctVN1/6WOeqxVDAYjQsmKu7zq1kW1cewW3me2e+z9f9TomD8ogZ9akthY2MbvRb9F0s9o4U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638127; c=relaxed/simple; bh=xrPn8N30OpMvKdopmq/6f3qMPBy3ZDBF1ilqqQlgy/s=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=asN5bF6VE4VtGvBQ8wWcwDkUSNOwP0/Y/Ie9rMtQo2tsCSnoq78K61dsjQiiLUwGbwiEJQ9On2azyittPYLAHU4Srpa8u5RpBLKF++h5JPvxh5keERzotl/jD5/ErcPk960zt97M5KYkynQmyWUoFsqyHwIoFn1xXbxm3u/tajc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=VaEFvKFT; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="VaEFvKFT" Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJINN2S003444; Thu, 19 Dec 2024 19:54:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=FltTR JgBvsFnxq3rKGOiF4qS7SsFv34utOpWFcvc7SQ=; b=VaEFvKFTQjlwksx/HpKUy CCxoSIU8CSubb+2r4u8+bc5om8C5WEiEiyTTcmDii07NOwj+ftT0PUwjjqXn8iJm r+llXN6pIcbrKjsjqwNJaF3Y9p0IQ7xDfYebFnrJycWpV69AcU/TfO6Hhbotw4W+ n0U9SAj7BcHlmEPb+M8tfkTTMCVPjAgVH8nDGx+DMuRUzHiNL0hRY1wpZzIY7TcA /IaA49gYJtrMvjP1aO8HB20RFTCNiw1VbqdfnSWUwYWRUq9nw2dMi8HDl49ofk6S SNHA00YfyotaFqssRiPCaOt9WUytc446qE2NUXklbYG/Hz8YLrz5JGTcDUAJayOG A== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h0m0c1us-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:54:38 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJJTTIA035475; Thu, 19 Dec 2024 19:54:36 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbnhny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:54:36 +0000 Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJsZMa035326; Thu, 19 Dec 2024 19:54:35 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbnhn5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:54:35 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 04/19] x86: Secure Launch main header file Date: Thu, 19 Dec 2024 11:42:01 -0800 Message-Id: <20241219194216.152839-5-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 spamscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: 9AIt3gNXJZDP_mLBn62fER6VzLL9hRqD X-Proofpoint-ORIG-GUID: 9AIt3gNXJZDP_mLBn62fER6VzLL9hRqD Introduce the main Secure Launch header file used in the early SL stub and the early setup code. Signed-off-by: Ross Philipson --- include/linux/slaunch.h | 547 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 547 insertions(+) create mode 100644 include/linux/slaunch.h diff --git a/include/linux/slaunch.h b/include/linux/slaunch.h new file mode 100644 index 000000000000..0950e14e7179 --- /dev/null +++ b/include/linux/slaunch.h @@ -0,0 +1,547 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Main Secure Launch header file. + * + * Copyright (c) 2024 Apertus Solutions, LLC + * Copyright (c) 2024, Oracle and/or its affiliates. + */ + +#ifndef _LINUX_SLAUNCH_H +#define _LINUX_SLAUNCH_H + +/* + * Secure Launch Defined State Flags + */ +#define SL_FLAG_ACTIVE 0x00000001 +#define SL_FLAG_ARCH_TXT 0x00000002 + +/* + * Secure Launch CPU Type + */ +#define SL_CPU_INTEL 1 + +#define __SL32_CS 0x0008 +#define __SL32_DS 0x0010 + +/* + * Intel Safer Mode Extensions (SMX) + * + * Intel SMX provides a programming interface to establish a Measured Launched + * Environment (MLE). The measurement and protection mechanisms supported by the + * capabilities of an Intel Trusted Execution Technology (TXT) platform. SMX is + * the processor's programming interface in an Intel TXT platform. + * + * See: + * Intel SDM Volume 2 - 6.1 "Safer Mode Extensions Reference" + * Intel Trusted Execution Technology - Measured Launch Environment Developer's Guide + */ + +/* + * SMX GETSEC Leaf Functions + */ +#define SMX_X86_GETSEC_SEXIT 5 +#define SMX_X86_GETSEC_SMCTRL 7 +#define SMX_X86_GETSEC_WAKEUP 8 + +/* + * Intel Trusted Execution Technology MMIO Registers Banks + */ +#define TXT_PUB_CONFIG_REGS_BASE 0xfed30000 +#define TXT_PRIV_CONFIG_REGS_BASE 0xfed20000 +#define TXT_NR_CONFIG_PAGES ((TXT_PUB_CONFIG_REGS_BASE - \ + TXT_PRIV_CONFIG_REGS_BASE) >> PAGE_SHIFT) + +/* + * Intel Trusted Execution Technology (TXT) Registers + */ +#define TXT_CR_STS 0x0000 +#define TXT_CR_ESTS 0x0008 +#define TXT_CR_ERRORCODE 0x0030 +#define TXT_CR_CMD_RESET 0x0038 +#define TXT_CR_CMD_CLOSE_PRIVATE 0x0048 +#define TXT_CR_DIDVID 0x0110 +#define TXT_CR_VER_EMIF 0x0200 +#define TXT_CR_CMD_UNLOCK_MEM_CONFIG 0x0218 +#define TXT_CR_SINIT_BASE 0x0270 +#define TXT_CR_SINIT_SIZE 0x0278 +#define TXT_CR_MLE_JOIN 0x0290 +#define TXT_CR_HEAP_BASE 0x0300 +#define TXT_CR_HEAP_SIZE 0x0308 +#define TXT_CR_SCRATCHPAD 0x0378 +#define TXT_CR_CMD_OPEN_LOCALITY1 0x0380 +#define TXT_CR_CMD_CLOSE_LOCALITY1 0x0388 +#define TXT_CR_CMD_OPEN_LOCALITY2 0x0390 +#define TXT_CR_CMD_CLOSE_LOCALITY2 0x0398 +#define TXT_CR_CMD_SECRETS 0x08e0 +#define TXT_CR_CMD_NO_SECRETS 0x08e8 +#define TXT_CR_E2STS 0x08f0 + +/* TXT default register value */ +#define TXT_REGVALUE_ONE 0x1ULL + +/* TXTCR_STS status bits */ +#define TXT_SENTER_DONE_STS BIT(0) +#define TXT_SEXIT_DONE_STS BIT(1) + +/* + * SINIT/MLE Capabilities Field Bit Definitions + */ +#define TXT_SINIT_MLE_CAP_WAKE_GETSEC 0 +#define TXT_SINIT_MLE_CAP_WAKE_MONITOR 1 + +/* + * OS/MLE Secure Launch Specific Definitions + */ +#define TXT_OS_MLE_STRUCT_VERSION 1 +#define TXT_OS_MLE_MAX_VARIABLE_MTRRS 32 + +/* + * TXT Heap Table Enumeration + */ +#define TXT_BIOS_DATA_TABLE 1 +#define TXT_OS_MLE_DATA_TABLE 2 +#define TXT_OS_SINIT_DATA_TABLE 3 +#define TXT_SINIT_MLE_DATA_TABLE 4 +#define TXT_SINIT_TABLE_MAX TXT_SINIT_MLE_DATA_TABLE + +/* + * Secure Launch Defined Error Codes used in MLE-initiated TXT resets. + * + * TXT Specification + * Appendix I ACM Error Codes + */ +#define SL_ERROR_GENERIC 0xc0008001 +#define SL_ERROR_TPM_INIT 0xc0008002 +#define SL_ERROR_TPM_INVALID_LOG20 0xc0008003 +#define SL_ERROR_TPM_LOGGING_FAILED 0xc0008004 +#define SL_ERROR_REGION_STRADDLE_4GB 0xc0008005 +#define SL_ERROR_TPM_EXTEND 0xc0008006 +#define SL_ERROR_MTRR_INV_VCNT 0xc0008007 +#define SL_ERROR_MTRR_INV_DEF_TYPE 0xc0008008 +#define SL_ERROR_MTRR_INV_BASE 0xc0008009 +#define SL_ERROR_MTRR_INV_MASK 0xc000800a +#define SL_ERROR_MSR_INV_MISC_EN 0xc000800b +#define SL_ERROR_INV_AP_INTERRUPT 0xc000800c +#define SL_ERROR_INTEGER_OVERFLOW 0xc000800d +#define SL_ERROR_HEAP_WALK 0xc000800e +#define SL_ERROR_HEAP_MAP 0xc000800f +#define SL_ERROR_REGION_ABOVE_4GB 0xc0008010 +#define SL_ERROR_HEAP_INVALID_DMAR 0xc0008011 +#define SL_ERROR_HEAP_DMAR_SIZE 0xc0008012 +#define SL_ERROR_HEAP_DMAR_MAP 0xc0008013 +#define SL_ERROR_HI_PMR_BASE 0xc0008014 +#define SL_ERROR_HI_PMR_SIZE 0xc0008015 +#define SL_ERROR_LO_PMR_BASE 0xc0008016 +#define SL_ERROR_LO_PMR_MLE 0xc0008017 +#define SL_ERROR_INITRD_TOO_BIG 0xc0008018 +#define SL_ERROR_HEAP_ZERO_OFFSET 0xc0008019 +#define SL_ERROR_WAKE_BLOCK_TOO_SMALL 0xc000801a +#define SL_ERROR_MLE_BUFFER_OVERLAP 0xc000801b +#define SL_ERROR_BUFFER_BEYOND_PMR 0xc000801c +#define SL_ERROR_OS_SINIT_BAD_VERSION 0xc000801d +#define SL_ERROR_EVENTLOG_MAP 0xc000801e +#define SL_ERROR_TPM_INVALID_ALGS 0xc000801f +#define SL_ERROR_TPM_EVENT_COUNT 0xc0008020 +#define SL_ERROR_TPM_INVALID_EVENT 0xc0008021 +#define SL_ERROR_INVALID_SLRT 0xc0008022 +#define SL_ERROR_SLRT_MISSING_ENTRY 0xc0008023 +#define SL_ERROR_SLRT_MAP 0xc0008024 + +/* + * Secure Launch Defined Limits + */ +#define TXT_MAX_CPUS 512 +#define TXT_BOOT_STACK_SIZE 128 + +/* + * Secure Launch event log entry type. The TXT specification defines the + * base event value as 0x400 for DRTM values. + */ +#define TXT_EVTYPE_BASE 0x400 +#define TXT_EVTYPE_SLAUNCH (TXT_EVTYPE_BASE + 0x102) +#define TXT_EVTYPE_SLAUNCH_START (TXT_EVTYPE_BASE + 0x103) +#define TXT_EVTYPE_SLAUNCH_END (TXT_EVTYPE_BASE + 0x104) + +/* + * MLE scratch area offsets + */ +#define SL_SCRATCH_AP_EBX 0 +#define SL_SCRATCH_AP_JMP_OFFSET 4 +#define SL_SCRATCH_AP_STACKS_OFFSET 8 + +#ifndef __ASSEMBLY__ + +#include +#include +#include + +/* + * Secure Launch AP stack and monitor block + */ +struct sl_ap_stack_and_monitor { + u32 monitor; + u32 cache_pad[15]; + u32 stack_pad[15]; + u32 apicid; +} __packed; + +/* + * Secure Launch AP wakeup information fetched in SMP boot code. + */ +struct sl_ap_wake_info { + u32 ap_wake_block; + u32 ap_wake_block_size; + u32 ap_jmp_offset; + u32 ap_stacks_offset; +}; + +/* + * TXT heap extended data elements. + */ +struct txt_heap_ext_data_element { + u32 type; + u32 size; + /* Data */ +} __packed; + +#define TXT_HEAP_EXTDATA_TYPE_END 0 + +struct txt_heap_end_element { + u32 type; + u32 size; +} __packed; + +#define TXT_HEAP_EXTDATA_TYPE_TPM_EVENT_LOG_PTR 5 + +struct txt_heap_event_log_element { + u64 event_log_phys_addr; +} __packed; + +#define TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1 8 + +struct txt_heap_event_log_pointer2_1_element { + u64 phys_addr; + u32 allocated_event_container_size; + u32 first_record_offset; + u32 next_record_offset; +} __packed; + +/* + * 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; + +/* + * TXT specification defined BIOS data TXT Heap table + */ +struct txt_bios_data { + u32 version; /* Currently 5 for TPM 1.2 and 6 for TPM 2.0 */ + u32 bios_sinit_size; + u64 reserved1; + u64 reserved2; + u32 num_logical_procs; + /* Versions >= 5 with updates in version 6 */ + u32 sinit_flags; + u32 mle_flags; + /* Versions >= 4 */ + /* Ext Data Elements */ +} __packed; + +/* + * TXT specification defined OS/SINIT TXT Heap table + */ +struct txt_os_sinit_data { + u32 version; /* Currently 6 for TPM 1.2 and 7 for TPM 2.0 */ + u32 flags; + u64 mle_ptab; + u64 mle_size; + u64 mle_hdr_base; + u64 vtd_pmr_lo_base; + u64 vtd_pmr_lo_size; + u64 vtd_pmr_hi_base; + u64 vtd_pmr_hi_size; + u64 lcp_po_base; + u64 lcp_po_size; + u32 capabilities; + /* Version = 5 */ + u64 efi_rsdt_ptr; + /* Versions >= 6 */ + /* Ext Data Elements */ +} __packed; + +/* + * TXT specification defined SINIT/MLE TXT Heap table + */ +struct txt_sinit_mle_data { + u32 version; /* Current values are 6 through 9 */ + /* Versions <= 8 */ + u8 bios_acm_id[20]; + u32 edx_senter_flags; + u64 mseg_valid; + u8 sinit_hash[20]; + u8 mle_hash[20]; + u8 stm_hash[20]; + u8 lcp_policy_hash[20]; + u32 lcp_policy_control; + /* Versions >= 7 */ + u32 rlp_wakeup_addr; + u32 reserved; + u32 num_of_sinit_mdrs; + u32 sinit_mdrs_table_offset; + u32 sinit_vtd_dmar_table_size; + u32 sinit_vtd_dmar_table_offset; + /* Versions >= 8 */ + u32 processor_scrtm_status; + /* Versions >= 9 */ + /* Ext Data Elements */ +} __packed; + +/* + * TXT data reporting structure for memory types + */ +struct txt_sinit_memory_descriptor_record { + u64 address; + u64 length; + u8 type; + u8 reserved[7]; +} __packed; + +/* + * TXT data structure used by a responsive local processor (RLP) to start + * execution in response to a GETSEC[WAKEUP]. + */ +struct smx_rlp_mle_join { + u32 rlp_gdt_limit; + u32 rlp_gdt_base; + u32 rlp_seg_sel; /* cs (ds, es, ss are seg_sel+8) */ + u32 rlp_entry_point; /* phys addr */ +} __packed; + +/* + * TPM event log structures defined in both the TXT specification and + * the TCG documentation. + */ +#define TPM_EVTLOG_SIGNATURE "TXT Event Container" + +struct tpm_event_log_header { + char signature[20]; + char reserved[12]; + u8 container_ver_major; + u8 container_ver_minor; + u8 pcr_event_ver_major; + u8 pcr_event_ver_minor; + u32 container_size; + u32 pcr_events_offset; + u32 next_event_offset; + /* PCREvents[] */ +} __packed; + +/* + * Functions to extract data from the Intel TXT Heap Memory. The layout + * of the heap is as follows: + * +----------------------------+ + * | Size Bios Data table (u64) | + * +----------------------------+ + * | Bios Data table | + * +----------------------------+ + * | Size OS MLE table (u64) | + * +----------------------------+ + * | OS MLE table | + * +--------------------------- + + * | Size OS SINIT table (u64) | + * +----------------------------+ + * | OS SINIT table | + * +----------------------------+ + * | Size SINIT MLE table (u64) | + * +----------------------------+ + * | SINIT MLE table | + * +----------------------------+ + * + * NOTE: the table size fields include the 8 byte size field itself. + */ +static inline u64 txt_bios_data_size(void *heap) +{ + return *((u64 *)heap); +} + +static inline void *txt_bios_data_start(void *heap) +{ + return heap + sizeof(u64); +} + +static inline u64 txt_os_mle_data_size(void *heap) +{ + return *((u64 *)(heap + txt_bios_data_size(heap))); +} + +static inline void *txt_os_mle_data_start(void *heap) +{ + return heap + txt_bios_data_size(heap) + sizeof(u64); +} + +static inline u64 txt_os_sinit_data_size(void *heap) +{ + return *((u64 *)(heap + txt_bios_data_size(heap) + + txt_os_mle_data_size(heap))); +} + +static inline void *txt_os_sinit_data_start(void *heap) +{ + return heap + txt_bios_data_size(heap) + + txt_os_mle_data_size(heap) + sizeof(u64); +} + +static inline u64 txt_sinit_mle_data_size(void *heap) +{ + return *((u64 *)(heap + txt_bios_data_size(heap) + + txt_os_mle_data_size(heap) + + txt_os_sinit_data_size(heap))); +} + +static inline void *txt_sinit_mle_data_start(void *heap) +{ + return heap + txt_bios_data_size(heap) + + txt_os_mle_data_size(heap) + + txt_os_sinit_data_size(heap) + sizeof(u64); +} + +#if IS_ENABLED(CONFIG_SECURE_LAUNCH) + +/* + * TPM event logging functions. + */ +static inline struct txt_heap_event_log_pointer2_1_element* +tpm2_find_log2_1_element(struct txt_os_sinit_data *os_sinit_data) +{ + struct txt_heap_ext_data_element *ext_elem; + + /* The extended element array as at the end of this table */ + ext_elem = (struct txt_heap_ext_data_element *) + ((u8 *)os_sinit_data + sizeof(struct txt_os_sinit_data)); + + while (ext_elem->type != TXT_HEAP_EXTDATA_TYPE_END) { + if (ext_elem->type == + TXT_HEAP_EXTDATA_TYPE_EVENT_LOG_POINTER2_1) { + return (struct txt_heap_event_log_pointer2_1_element *) + ((u8 *)ext_elem + + sizeof(struct txt_heap_ext_data_element)); + } + ext_elem = + (struct txt_heap_ext_data_element *) + ((u8 *)ext_elem + ext_elem->size); + } + + return NULL; +} + +static inline int tpm_log_event(void *evtlog_base, u32 evtlog_size, + u32 event_size, void *event) +{ + struct tpm_event_log_header *evtlog = + (struct tpm_event_log_header *)evtlog_base; + + if (memcmp(evtlog->signature, TPM_EVTLOG_SIGNATURE, + sizeof(TPM_EVTLOG_SIGNATURE))) + return -EINVAL; + + if (evtlog->container_size > evtlog_size) + return -EINVAL; + + if (evtlog->next_event_offset + event_size > evtlog->container_size) + return -E2BIG; + + memcpy(evtlog_base + evtlog->next_event_offset, event, event_size); + evtlog->next_event_offset += event_size; + + return 0; +} + +static inline int tpm2_log_event(struct txt_heap_event_log_pointer2_1_element *elem, + void *evtlog_base, u32 evtlog_size, + u32 event_size, void *event) +{ + struct tcg_pcr_event *header = + (struct tcg_pcr_event *)evtlog_base; + + /* Has to be at least big enough for the signature */ + if (header->event_size < sizeof(TCG_SPECID_SIG)) + return -EINVAL; + + if (memcmp((u8 *)header + sizeof(struct tcg_pcr_event), + TCG_SPECID_SIG, sizeof(TCG_SPECID_SIG))) + return -EINVAL; + + if (elem->allocated_event_container_size > evtlog_size) + return -EINVAL; + + if (elem->next_record_offset + event_size > + elem->allocated_event_container_size) + return -E2BIG; + + memcpy(evtlog_base + elem->next_record_offset, event, event_size); + elem->next_record_offset += event_size; + + return 0; +} + +/* + * External functions avalailable in mainline kernel. + */ +void slaunch_setup_txt(void); +void slaunch_fixup_jump_vector(void); +u32 slaunch_get_flags(void); +struct sl_ap_wake_info *slaunch_get_ap_wake_info(void); +struct acpi_table_header *slaunch_get_dmar_table(struct acpi_table_header *dmar); +void __noreturn slaunch_txt_reset(void __iomem *txt, + const char *msg, u64 error); +void slaunch_finalize(int do_sexit); + +static inline bool slaunch_is_txt_launch(void) +{ + u32 mask = SL_FLAG_ACTIVE | SL_FLAG_ARCH_TXT; + + return (slaunch_get_flags() & mask) == mask; +} + +#else + +static inline void slaunch_setup_txt(void) +{ +} + +static inline void slaunch_fixup_jump_vector(void) +{ +} + +static inline u32 slaunch_get_flags(void) +{ + return 0; +} + +static inline struct acpi_table_header *slaunch_get_dmar_table(struct acpi_table_header *dmar) +{ + return dmar; +} + +static inline void slaunch_finalize(int do_sexit) +{ +} + +static inline bool slaunch_is_txt_launch(void) +{ + return false; +} + +#endif /* !IS_ENABLED(CONFIG_SECURE_LAUNCH) */ + +#endif /* !__ASSEMBLY */ + +#endif /* _LINUX_SLAUNCH_H */ From patchwork Thu Dec 19 19:42:07 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852155 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 129E61BEF7A; Thu, 19 Dec 2024 19:55:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.177.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638160; cv=none; b=nOqmck78asfvoQP/D9PCrbDGRFpGqtwSVVmmEsVOcDvEb2eOtyxVRQCAZKcodUlHcX0FN/z9mPtpheVL22TvGdehorm/2HgGlNZJ9blLHf5R2HQbD4GRlI31aMl334QsZhZM0YNT3Bn+LAnDFaHWFZ0PkPEfFHhCqYhWy+yHHkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638160; c=relaxed/simple; bh=iuzDGbCzefFrodnMrf2gS/Ut6dodylmOPn/CmM+6nmU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GB0rajorJZ+pxa5bttzgMmRPmxZit2HUgVpUf5lWPPp2qD9uqUWS36h+xCoS/oPVDe0HawHQCIv4PwpQblNaNp284Umu9WmULgg/A77DiIDS5d+tb2BkukzlyLxe6VeExo+4gWGEJ1HdgQDIFFRGUsaAQkE0aVYOPbQwkh/yDLc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=H32XXExb; arc=none smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="H32XXExb" Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMi85029775; Thu, 19 Dec 2024 19:55:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=8BM4W GlBSZnhfydWX7PmXAqxipVK8kbW5F2YxOUjxaA=; b=H32XXExb3LTchL13AqCaB 7IQFnnowX6PZpiEXU4kKgxCCHKfyprOoN4N3YzSaPANGnMOjnS0gjjCMMjSGzMz/ bhgUBtbPr314RQiDrHDiA7y7SDLlUFwH/WKRgCSYZbsfaqQe5AKxcfAsuG56wd7T n2P8m4JNipUWv7uRonC0XKgFacT0dCtiZMGrdjeEjJ8sA5usI+ptlPKm6aP6Pa20 NW7mOQNGBmUN9OtvBgI0ISp/hfoWSf/EvTqJkgcjQ7s2uffjxuGPiVfvdQD935J4 dhyCq3cbU4L2X1UWV7ipDGk7N8jv4cDi3TSLvvQdXJnPgYyuBw4KIZtprRmje/gB w== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h22cuv9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:55:33 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJJp4fE035469; Thu, 19 Dec 2024 19:55:32 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbnjng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:55:32 +0000 Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJrbXm032931; Thu, 19 Dec 2024 19:55:31 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbnjmk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:55:31 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 10/19] x86: Secure Launch kernel late boot stub Date: Thu, 19 Dec 2024 11:42:07 -0800 Message-Id: <20241219194216.152839-11-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 spamscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: 8Z4-SpqMdlSFx_iptexUzh9St3Z5IcAJ X-Proofpoint-ORIG-GUID: 8Z4-SpqMdlSFx_iptexUzh9St3Z5IcAJ The routine slaunch_setup is called out of the x86 specific setup_arch() routine during early kernel boot. After determining what platform is present, various operations specific to that platform occur. This includes finalizing setting for the platform late launch and verifying that memory protections are in place. Intel VT-d/IOMMU hardware provides special registers called Protected Memory Regions (PMRs) that allow all memory to be protected from DMA during a TXT DRTM launch. This coverage is validated during the late setup process to ensure DMA protection is in place prior to the IOMMUs being initialized and configured by the mainline kernel. See the Intel Trusted Execution Technology - Measured Launch Environment Developer's Guide for more details. For TXT, this code also reserves the original compressed kernel setup area where the APs were left looping so that this memory cannot be used. Signed-off-by: Ross Philipson --- arch/x86/kernel/Makefile | 1 + arch/x86/kernel/setup.c | 3 + arch/x86/kernel/slaunch.c | 524 +++++++++++++++++++++++++++++++++++++ drivers/iommu/intel/dmar.c | 4 + 4 files changed, 532 insertions(+) create mode 100644 arch/x86/kernel/slaunch.c diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index f7918980667a..f3a6518ea248 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -80,6 +80,7 @@ obj-$(CONFIG_X86_32) += tls.o obj-$(CONFIG_IA32_EMULATION) += tls.o obj-y += step.o obj-$(CONFIG_INTEL_TXT) += tboot.o +obj-$(CONFIG_SECURE_LAUNCH) += slaunch.o obj-$(CONFIG_ISA_DMA_API) += i8237.o obj-y += stacktrace.o obj-y += cpu/ diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index f1fea506e20f..fc63b57cd207 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -938,6 +939,8 @@ void __init setup_arch(char **cmdline_p) early_gart_iommu_check(); #endif + slaunch_setup_txt(); + /* * partially used pages are not usable - thus * we are rounding upwards: diff --git a/arch/x86/kernel/slaunch.c b/arch/x86/kernel/slaunch.c new file mode 100644 index 000000000000..5c54288ce980 --- /dev/null +++ b/arch/x86/kernel/slaunch.c @@ -0,0 +1,524 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Secure Launch late validation/setup and finalization support. + * + * Copyright (c) 2024, Oracle and/or its affiliates. + */ + +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +static u32 sl_flags __ro_after_init; +static struct sl_ap_wake_info ap_wake_info __ro_after_init; +static u64 evtlog_addr __ro_after_init; +static u32 evtlog_size __ro_after_init; +static u64 vtd_pmr_lo_size __ro_after_init; + +/* This should be plenty of room */ +static u8 txt_dmar[PAGE_SIZE] __aligned(16); + +/* + * Get the Secure Launch flags that indicate what kind of launch is being done. + * E.g. a TXT launch is in progress or no Secure Launch is happening. + */ +u32 slaunch_get_flags(void) +{ + return sl_flags; +} + +/* + * Return the AP wakeup information used in the SMP boot code to start up + * the APs that are parked using MONITOR/MWAIT. + */ +struct sl_ap_wake_info *slaunch_get_ap_wake_info(void) +{ + return &ap_wake_info; +} + +/* + * On Intel platforms, TXT passes a safe copy of the DMAR ACPI table to the + * DRTM. The DRTM is supposed to use this instead of the one found in the + * ACPI tables. + */ +struct acpi_table_header *slaunch_get_dmar_table(struct acpi_table_header *dmar) +{ + /* The DMAR is only stashed and provided via TXT on Intel systems */ + if (memcmp(txt_dmar, "DMAR", 4)) + return dmar; + + return (struct acpi_table_header *)(txt_dmar); +} + +/* + * If running within a TXT established DRTM, this is the proper way to reset + * the system if a failure occurs or a security issue is found. + */ +void __noreturn slaunch_txt_reset(void __iomem *txt, + const char *msg, u64 error) +{ + u64 one = 1, val; + + pr_err("%s", msg); + + /* + * This performs a TXT reset with a sticky error code. The reads of + * TXT_CR_E2STS act as barriers. + */ + memcpy_toio(txt + TXT_CR_ERRORCODE, &error, sizeof(error)); + memcpy_fromio(&val, txt + TXT_CR_E2STS, sizeof(val)); + memcpy_toio(txt + TXT_CR_CMD_NO_SECRETS, &one, sizeof(one)); + memcpy_fromio(&val, txt + TXT_CR_E2STS, sizeof(val)); + memcpy_toio(txt + TXT_CR_CMD_UNLOCK_MEM_CONFIG, &one, sizeof(one)); + memcpy_fromio(&val, txt + TXT_CR_E2STS, sizeof(val)); + memcpy_toio(txt + TXT_CR_CMD_RESET, &one, sizeof(one)); + + for ( ; ; ) + asm volatile ("hlt"); + + unreachable(); +} + +/* + * The TXT heap is too big to map all at once with early_ioremap + * so it is done a table at a time. + */ +static void __init *txt_early_get_heap_table(void __iomem *txt, u32 type, + u32 bytes) +{ + u64 base, size, offset = 0; + void *heap; + int i; + + if (type > TXT_SINIT_TABLE_MAX) + slaunch_txt_reset(txt, "Error invalid table type for early heap walk\n", + SL_ERROR_HEAP_WALK); + + memcpy_fromio(&base, txt + TXT_CR_HEAP_BASE, sizeof(base)); + memcpy_fromio(&size, txt + TXT_CR_HEAP_SIZE, sizeof(size)); + + /* Iterate over heap tables looking for table of "type" */ + for (i = 0; i < type; i++) { + base += offset; + heap = early_memremap(base, sizeof(u64)); + if (!heap) + slaunch_txt_reset(txt, "Error early_memremap of heap for heap walk\n", + SL_ERROR_HEAP_MAP); + + offset = *((u64 *)heap); + + /* + * After the first iteration, any offset of zero is invalid and + * implies the TXT heap is corrupted. + */ + if (!offset) + slaunch_txt_reset(txt, "Error invalid 0 offset in heap walk\n", + SL_ERROR_HEAP_ZERO_OFFSET); + + early_memunmap(heap, sizeof(u64)); + } + + /* Skip the size field at the head of each table */ + base += sizeof(u64); + heap = early_memremap(base, bytes); + if (!heap) + slaunch_txt_reset(txt, "Error early_memremap of heap section\n", + SL_ERROR_HEAP_MAP); + + return heap; +} + +static void __init txt_early_put_heap_table(void *addr, unsigned long size) +{ + early_memunmap(addr, size); +} + +/* + * TXT uses a special set of VTd registers to protect all of memory from DMA + * until the IOMMU can be programmed to protect memory. There is the low + * memory PMR that can protect all memory up to 4G. The high memory PRM can + * be setup to protect all memory beyond 4Gb. Validate that these values cover + * what is expected. + */ +static void __init slaunch_verify_pmrs(void __iomem *txt) +{ + struct txt_os_sinit_data *os_sinit_data; + u32 field_offset, err = 0; + const char *errmsg = ""; + unsigned long last_pfn; + + field_offset = offsetof(struct txt_os_sinit_data, lcp_po_base); + os_sinit_data = txt_early_get_heap_table(txt, TXT_OS_SINIT_DATA_TABLE, + field_offset); + + /* Save a copy */ + vtd_pmr_lo_size = os_sinit_data->vtd_pmr_lo_size; + + last_pfn = e820__end_of_ram_pfn(); + + /* + * First make sure the hi PMR covers all memory above 4G. In the + * unlikely case where there is < 4G on the system, the hi PMR will + * not be set. + */ + if (os_sinit_data->vtd_pmr_hi_base != 0x0ULL) { + if (os_sinit_data->vtd_pmr_hi_base != 0x100000000ULL) { + err = SL_ERROR_HI_PMR_BASE; + errmsg = "Error hi PMR base\n"; + goto out; + } + + if (PFN_PHYS(last_pfn) > os_sinit_data->vtd_pmr_hi_base + + os_sinit_data->vtd_pmr_hi_size) { + err = SL_ERROR_HI_PMR_SIZE; + errmsg = "Error hi PMR size\n"; + goto out; + } + } + + /* + * Lo PMR base should always be 0. This was already checked in + * early stub. + */ + + /* + * Check that if the kernel was loaded below 4G, that it is protected + * by the lo PMR. Note this is the decompressed kernel. The ACM would + * have ensured the compressed kernel (the MLE image) was protected. + */ + if (__pa_symbol(_end) < 0x100000000ULL && __pa_symbol(_end) > os_sinit_data->vtd_pmr_lo_size) { + err = SL_ERROR_LO_PMR_MLE; + errmsg = "Error lo PMR does not cover MLE kernel\n"; + } + + /* + * Other regions of interest like boot param, AP wake block, cmdline + * already checked for PMR coverage in the early stub code. + */ + +out: + txt_early_put_heap_table(os_sinit_data, field_offset); + + if (err) + slaunch_txt_reset(txt, errmsg, err); +} + +static void __init slaunch_txt_reserve_range(u64 base, u64 size) +{ + int type; + + type = e820__get_entry_type(base, base + size - 1); + if (type == E820_TYPE_RAM) { + pr_info("memblock reserve base: %llx size: %llx\n", base, size); + memblock_reserve(base, size); + } +} + +/* + * For Intel, certain regions of memory must be marked as reserved by putting + * them on the memblock reserved list if they are not already e820 reserved. + * This includes: + * - The TXT HEAP + * - The ACM area + * - The TXT private register bank + * - The MDR list sent to the MLE by the ACM (see TXT specification) + * (Normally the above are properly reserved by firmware but if it was not + * done, reserve them now) + * - The AP wake block + * - TPM log external to the TXT heap + * + * Also if the low PMR doesn't cover all memory < 4G, any RAM regions above + * the low PMR must be reserved too. + */ +static void __init slaunch_txt_reserve(void __iomem *txt) +{ + struct txt_sinit_memory_descriptor_record *mdr; + struct txt_sinit_mle_data *sinit_mle_data; + u64 base, size, heap_base, heap_size; + u32 mdrnum, mdroffset, mdrslen; + u32 field_offset, i; + void *mdrs; + + base = TXT_PRIV_CONFIG_REGS_BASE; + size = TXT_PUB_CONFIG_REGS_BASE - TXT_PRIV_CONFIG_REGS_BASE; + slaunch_txt_reserve_range(base, size); + + memcpy_fromio(&heap_base, txt + TXT_CR_HEAP_BASE, sizeof(heap_base)); + memcpy_fromio(&heap_size, txt + TXT_CR_HEAP_SIZE, sizeof(heap_size)); + slaunch_txt_reserve_range(heap_base, heap_size); + + memcpy_fromio(&base, txt + TXT_CR_SINIT_BASE, sizeof(base)); + memcpy_fromio(&size, txt + TXT_CR_SINIT_SIZE, sizeof(size)); + slaunch_txt_reserve_range(base, size); + + field_offset = offsetof(struct txt_sinit_mle_data, + sinit_vtd_dmar_table_size); + sinit_mle_data = txt_early_get_heap_table(txt, TXT_SINIT_MLE_DATA_TABLE, + field_offset); + + mdrnum = sinit_mle_data->num_of_sinit_mdrs; + mdroffset = sinit_mle_data->sinit_mdrs_table_offset; + + txt_early_put_heap_table(sinit_mle_data, field_offset); + + if (!mdrnum) + goto nomdr; + + mdrslen = mdrnum * sizeof(*mdr); + + mdrs = txt_early_get_heap_table(txt, TXT_SINIT_MLE_DATA_TABLE, + mdroffset + mdrslen - 8); + + mdr = mdrs + mdroffset - 8; + + for (i = 0; i < mdrnum; i++, mdr++) { + /* Spec says some entries can have length 0, ignore them */ + if (mdr->type > 0 && mdr->length > 0) + slaunch_txt_reserve_range(mdr->address, mdr->length); + } + + txt_early_put_heap_table(mdrs, mdroffset + mdrslen - 8); + +nomdr: + slaunch_txt_reserve_range(ap_wake_info.ap_wake_block, + ap_wake_info.ap_wake_block_size); + + /* + * Earlier checks ensured that the event log was properly situated + * either inside the TXT heap or outside. This is a check to see if the + * event log needs to be reserved. If it is in the TXT heap, it is + * already reserved. + */ + if (evtlog_addr < heap_base || evtlog_addr > (heap_base + heap_size)) + slaunch_txt_reserve_range(evtlog_addr, evtlog_size); + + for (i = 0; i < e820_table->nr_entries; i++) { + base = e820_table->entries[i].addr; + size = e820_table->entries[i].size; + if (base >= vtd_pmr_lo_size && base < 0x100000000ULL) + slaunch_txt_reserve_range(base, size); + else if (base < vtd_pmr_lo_size && base + size > vtd_pmr_lo_size) + slaunch_txt_reserve_range(vtd_pmr_lo_size, + base + size - vtd_pmr_lo_size); + } +} + +/* + * TXT stashes a safe copy of the DMAR ACPI table to prevent tampering. + * It is stored in the TXT heap. Fetch it from there and make it available + * to the IOMMU driver. + */ +static void __init slaunch_copy_dmar_table(void __iomem *txt) +{ + struct txt_sinit_mle_data *sinit_mle_data; + u32 field_offset, dmar_size, dmar_offset; + void *dmar; + + field_offset = offsetof(struct txt_sinit_mle_data, + processor_scrtm_status); + sinit_mle_data = txt_early_get_heap_table(txt, TXT_SINIT_MLE_DATA_TABLE, + field_offset); + + dmar_size = sinit_mle_data->sinit_vtd_dmar_table_size; + dmar_offset = sinit_mle_data->sinit_vtd_dmar_table_offset; + + txt_early_put_heap_table(sinit_mle_data, field_offset); + + if (!dmar_size || !dmar_offset) + slaunch_txt_reset(txt, "Error invalid DMAR table values\n", + SL_ERROR_HEAP_INVALID_DMAR); + + if (unlikely(dmar_size > PAGE_SIZE)) + slaunch_txt_reset(txt, "Error DMAR too big to store\n", + SL_ERROR_HEAP_DMAR_SIZE); + + dmar = txt_early_get_heap_table(txt, TXT_SINIT_MLE_DATA_TABLE, + dmar_offset + dmar_size - 8); + if (!dmar) + slaunch_txt_reset(txt, "Error early_ioremap of DMAR\n", + SL_ERROR_HEAP_DMAR_MAP); + + memcpy(txt_dmar, dmar + dmar_offset - 8, dmar_size); + + txt_early_put_heap_table(dmar, dmar_offset + dmar_size - 8); +} + +/* + * The location of the safe AP wake code block is stored in the TXT heap. + * Fetch needed values here in the early init code for later use in SMP + * startup. + * + * Also get the TPM event log values are in the SLRT and have to be fetched. + * They will be put on the memblock reserve list later. + */ +static void __init slaunch_fetch_values(void __iomem *txt) +{ + struct txt_os_mle_data *os_mle_data; + struct slr_entry_log_info *log_info; + u8 *jmp_offset, *stacks_offset; + struct slr_table *slrt; + u32 size; + + os_mle_data = txt_early_get_heap_table(txt, TXT_OS_MLE_DATA_TABLE, + sizeof(*os_mle_data)); + + ap_wake_info.ap_wake_block = os_mle_data->ap_wake_block; + ap_wake_info.ap_wake_block_size = os_mle_data->ap_wake_block_size; + + jmp_offset = os_mle_data->mle_scratch + SL_SCRATCH_AP_JMP_OFFSET; + ap_wake_info.ap_jmp_offset = *((u32 *)jmp_offset); + + stacks_offset = os_mle_data->mle_scratch + SL_SCRATCH_AP_STACKS_OFFSET; + ap_wake_info.ap_stacks_offset = *((u32 *)stacks_offset); + + slrt = (struct slr_table *)early_memremap(os_mle_data->slrt, sizeof(*slrt)); + if (!slrt) + slaunch_txt_reset(txt, "Error early_memremap of SLRT failed\n", + SL_ERROR_SLRT_MAP); + + size = slrt->size; + early_memunmap(slrt, sizeof(*slrt)); + + slrt = (struct slr_table *)early_memremap(os_mle_data->slrt, size); + if (!slrt) + slaunch_txt_reset(txt, "Error early_memremap of SLRT failed\n", + SL_ERROR_SLRT_MAP); + + log_info = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_LOG_INFO); + + if (!log_info) + slaunch_txt_reset(txt, "SLRT missing logging info entry\n", + SL_ERROR_SLRT_MISSING_ENTRY); + + evtlog_addr = log_info->addr; + evtlog_size = log_info->size; + + early_memunmap(slrt, size); + + txt_early_put_heap_table(os_mle_data, sizeof(*os_mle_data)); +} + +/* + * Called to fix the long jump address for the waiting APs to vector to + * the correct startup location in the Secure Launch stub in the rmpiggy. + */ +void __init slaunch_fixup_jump_vector(void) +{ + struct sl_ap_wake_info *ap_wake_info; + u32 *ap_jmp_ptr; + + if (!slaunch_is_txt_launch()) + return; + + ap_wake_info = slaunch_get_ap_wake_info(); + + ap_jmp_ptr = (u32 *)__va(ap_wake_info->ap_wake_block + + ap_wake_info->ap_jmp_offset); + + *ap_jmp_ptr = real_mode_header->sl_trampoline_start32; + + pr_info("TXT AP startup vector address updated\n"); +} + +/* + * Intel TXT specific late stub setup and validation called from within + * x86 specific setup_arch(). + */ +void __init slaunch_setup_txt(void) +{ + u64 one = TXT_REGVALUE_ONE, val; + void __iomem *txt; + + if (!boot_cpu_has(X86_FEATURE_SMX)) + return; + + /* + * If booted through secure launch entry point, the loadflags + * option will be set. + */ + if (!(boot_params.hdr.loadflags & SLAUNCH_FLAG)) + return; + + /* + * See if SENTER was done by reading the status register in the + * public space. If the public register space cannot be read, TXT may + * be disabled. + */ + txt = early_ioremap(TXT_PUB_CONFIG_REGS_BASE, + TXT_NR_CONFIG_PAGES * PAGE_SIZE); + if (!txt) + panic("Error early_ioremap in TXT setup failed\n"); + + memcpy_fromio(&val, txt + TXT_CR_STS, sizeof(val)); + early_iounmap(txt, TXT_NR_CONFIG_PAGES * PAGE_SIZE); + + /* SENTER should have been done */ + if (!(val & TXT_SENTER_DONE_STS)) + panic("Error TXT.STS SENTER_DONE not set\n"); + + /* SEXIT should have been cleared */ + if (val & TXT_SEXIT_DONE_STS) + panic("Error TXT.STS SEXIT_DONE set\n"); + + /* Now we want to use the private register space */ + txt = early_ioremap(TXT_PRIV_CONFIG_REGS_BASE, + TXT_NR_CONFIG_PAGES * PAGE_SIZE); + if (!txt) { + /* This is really bad, no where to go from here */ + panic("Error early_ioremap of TXT priv registers\n"); + } + + /* + * Try to read the Intel VID from the TXT private registers to see if + * TXT measured launch happened properly and the private space is + * available. + */ + memcpy_fromio(&val, txt + TXT_CR_DIDVID, sizeof(val)); + if ((val & 0xffff) != 0x8086) { + /* + * Can't do a proper TXT reset since it appears something is + * wrong even though SENTER happened and it should be in SMX + * mode. + */ + panic("Invalid TXT vendor ID, not in SMX mode\n"); + } + + /* Set flags so subsequent code knows the status of the launch */ + sl_flags |= (SL_FLAG_ACTIVE | SL_FLAG_ARCH_TXT); + + /* + * Reading the proper DIDVID from the private register space means we + * are in SMX mode and private registers are open for read/write. + */ + + /* On Intel, have to handle TPM localities via TXT */ + memcpy_toio(txt + TXT_CR_CMD_SECRETS, &one, sizeof(one)); + memcpy_fromio(&val, txt + TXT_CR_E2STS, sizeof(val)); + memcpy_toio(txt + TXT_CR_CMD_OPEN_LOCALITY1, &one, sizeof(one)); + memcpy_fromio(&val, txt + TXT_CR_E2STS, sizeof(val)); + + slaunch_fetch_values(txt); + + slaunch_verify_pmrs(txt); + + slaunch_txt_reserve(txt); + + slaunch_copy_dmar_table(txt); + + early_iounmap(txt, TXT_NR_CONFIG_PAGES * PAGE_SIZE); + + pr_info("Intel TXT setup complete\n"); +} diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 9f424acf474e..4f2674f7df9c 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include "iommu.h" @@ -661,6 +662,9 @@ parse_dmar_table(void) */ dmar_tbl = tboot_get_dmar_table(dmar_tbl); + /* If Secure Launch is active, it has similar logic */ + dmar_tbl = slaunch_get_dmar_table(dmar_tbl); + dmar = (struct acpi_table_dmar *)dmar_tbl; if (!dmar) return -ENODEV; From patchwork Thu Dec 19 19:42:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852154 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 281E41C1F05; Thu, 19 Dec 2024 19:56:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638171; cv=none; b=Fd/q5dYZsCtkFwWZLZA1rjlEvPGuoWEK+nCP6/S1HFVuf2DTB7ROggyFi23E9yXHV7Xrj17DB8ht8HtwMECw4JR/Nt6ClfRhYBmzJH4Pgw8awVodpRMQWXWq8uyj5gqteHwCMcTfqr707r+3r5t3zfe2J3mzYO0J8YYEvj85104= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638171; c=relaxed/simple; bh=5Qbm/ZwWyEcaBbZIhrGHs+bPKxdsJWAk3L96AxFjAmw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rrPwSoNfqL/JHS2ZLQozjySP7DzVjRnlwe8RJj6ZAalwZ5g/OIOIwQrTEFXPpH+MHuxD6fH7ytU2V6CJQhfuKQ2QP4fN9SV5MyLSXxxATXqthsTD4IibT2SwNmeHtjHcvRK3cXlhSe9yr2vXoMeq7da6AvixSZPghkx0CBPznEA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=AYt5yKzJ; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="AYt5yKzJ" Received: from pps.filterd (m0333521.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMjbB028193; Thu, 19 Dec 2024 19:55:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=IpsTo bJ04sYQOJBIvjI0eq+ZVmpFmQLHLX6nTaCMkoo=; b=AYt5yKzJtMgs9sFIlsoPR 9MG8q5HLET87pevWhCDYB8p8+/96hFXtaTS8knIMHUyACSKDNyEiOEFIiy0XQZ3B 4YKnGZEUuWaGgkaL0i6h5kenvangnb6/TWrBItJEO7rXH+nOHmryO9JCpW8gT3rO u/LBGWFbIufJBHWAAmcjZ1SC8q+3W2+zPPMpeZPcLVmnKSEqfuc03mLr35vxcxcC +xxiE12UhdMPksbUAVyANMEzKsoIq/4Nbw59bWeYWjytWMwpJwYqV64oRgwiqFrK yAdj0k7oxRN4Fz9g9kKPGB7TkD9IKA3J5jZDb0wDG1Nrx9vZWhKv2RjBc3MyLMMb Q== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h0xb3y5k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:55:43 +0000 (GMT) Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJJFKEY006410; Thu, 19 Dec 2024 19:55:42 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fcgn0t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:55:42 +0000 Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJtf5V020884; Thu, 19 Dec 2024 19:55:41 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fcgmx5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:55:41 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 11/19] x86: Secure Launch SMP bringup support Date: Thu, 19 Dec 2024 11:42:08 -0800 Message-Id: <20241219194216.152839-12-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: r08Hna-QKYdylXcBGTbtecHGo1SrtQrR X-Proofpoint-ORIG-GUID: r08Hna-QKYdylXcBGTbtecHGo1SrtQrR On Intel, the APs are left in a well documented state after TXT performs the late launch. Specifically they cannot have #INIT asserted on them so a standard startup via INIT/SIPI/SIPI cannot be performed. Instead the early SL stub code uses MONITOR and MWAIT to park the APs. The realmode/init.c code updates the jump address for the waiting APs with the location of the Secure Launch entry point in the RM piggy after it is loaded and fixed up. As the APs are woken up by writing the monitor, the APs jump to the Secure Launch entry point in the RM piggy which mimics what the real mode code would do then jumps to the standard RM piggy protected mode entry point. Signed-off-by: Ross Philipson --- arch/x86/include/asm/realmode.h | 3 ++ arch/x86/kernel/smpboot.c | 43 ++++++++++++++++++++++++++-- arch/x86/realmode/init.c | 3 ++ arch/x86/realmode/rm/header.S | 3 ++ arch/x86/realmode/rm/trampoline_64.S | 32 +++++++++++++++++++++ 5 files changed, 82 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h index 87e5482acd0d..339b48e2543d 100644 --- a/arch/x86/include/asm/realmode.h +++ b/arch/x86/include/asm/realmode.h @@ -38,6 +38,9 @@ struct real_mode_header { #ifdef CONFIG_X86_64 u32 machine_real_restart_seg; #endif +#ifdef CONFIG_SECURE_LAUNCH + u32 sl_trampoline_start32; +#endif }; /* This must match data at realmode/rm/trampoline_{32,64}.S */ diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index b5a8f0891135..fafd062603b3 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -61,6 +61,7 @@ #include #include #include +#include #include #include @@ -870,6 +871,41 @@ int common_cpu_up(unsigned int cpu, struct task_struct *idle) return 0; } +#ifdef CONFIG_SECURE_LAUNCH + +/* + * TXT AP startup is quite different than normal. The APs cannot have #INIT + * asserted on them or receive SIPIs. The early Secure Launch code has parked + * the APs using monitor/mwait. This will wake the APs by writing the monitor + * and have them jump to the protected mode code in the rmpiggy where the rest + * of the SMP boot of the AP will proceed normally. + */ +static void slaunch_wakeup_cpu_from_txt(int cpu, int apicid) +{ + struct sl_ap_stack_and_monitor *stack_monitor; + struct sl_ap_wake_info *ap_wake_info; + + ap_wake_info = slaunch_get_ap_wake_info(); + + stack_monitor = (struct sl_ap_stack_and_monitor *)__va(ap_wake_info->ap_wake_block + + ap_wake_info->ap_stacks_offset); + + for (unsigned int i = TXT_MAX_CPUS - 1; i >= 0; i--) { + if (stack_monitor[i].apicid == apicid) { + stack_monitor[i].monitor = 1; + break; + } + } +} + +#else + +static inline void slaunch_wakeup_cpu_from_txt(int cpu, int apicid) +{ +} + +#endif /* !CONFIG_SECURE_LAUNCH */ + /* * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad * (ie clustered apic addressing mode), this is a LOGICAL apic ID. @@ -879,7 +915,7 @@ int common_cpu_up(unsigned int cpu, struct task_struct *idle) static int do_boot_cpu(u32 apicid, int cpu, struct task_struct *idle) { unsigned long start_ip = real_mode_header->trampoline_start; - int ret; + int ret = 0; #ifdef CONFIG_X86_64 /* If 64-bit wakeup method exists, use the 64-bit mode trampoline IP */ @@ -924,12 +960,15 @@ static int do_boot_cpu(u32 apicid, int cpu, struct task_struct *idle) /* * Wake up a CPU in difference cases: + * - Intel TXT DRTM launch uses its own method to wake the APs * - Use a method from the APIC driver if one defined, with wakeup * straight to 64-bit mode preferred over wakeup to RM. * Otherwise, * - Use an INIT boot APIC message */ - if (apic->wakeup_secondary_cpu_64) + if (slaunch_is_txt_launch()) + slaunch_wakeup_cpu_from_txt(cpu, apicid); + else if (apic->wakeup_secondary_cpu_64) ret = apic->wakeup_secondary_cpu_64(apicid, start_ip); else if (apic->wakeup_secondary_cpu) ret = apic->wakeup_secondary_cpu(apicid, start_ip); diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c index f9bc444a3064..d95776cb30d3 100644 --- a/arch/x86/realmode/init.c +++ b/arch/x86/realmode/init.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include @@ -210,6 +211,8 @@ void __init init_real_mode(void) setup_real_mode(); set_real_mode_permissions(); + + slaunch_fixup_jump_vector(); } static int __init do_init_real_mode(void) diff --git a/arch/x86/realmode/rm/header.S b/arch/x86/realmode/rm/header.S index 2eb62be6d256..3b5cbcbbfc90 100644 --- a/arch/x86/realmode/rm/header.S +++ b/arch/x86/realmode/rm/header.S @@ -37,6 +37,9 @@ SYM_DATA_START(real_mode_header) #ifdef CONFIG_X86_64 .long __KERNEL32_CS #endif +#ifdef CONFIG_SECURE_LAUNCH + .long pa_sl_trampoline_start32 +#endif SYM_DATA_END(real_mode_header) /* End signature, used to verify integrity */ diff --git a/arch/x86/realmode/rm/trampoline_64.S b/arch/x86/realmode/rm/trampoline_64.S index 14d9c7daf90f..b0ce6205d7ea 100644 --- a/arch/x86/realmode/rm/trampoline_64.S +++ b/arch/x86/realmode/rm/trampoline_64.S @@ -122,6 +122,38 @@ SYM_CODE_END(sev_es_trampoline_start) .section ".text32","ax" .code32 +#ifdef CONFIG_SECURE_LAUNCH + .balign 4 +SYM_CODE_START(sl_trampoline_start32) + /* + * The early secure launch stub AP wakeup code has taken care of all + * the vagaries of launching out of TXT. This bit just mimics what the + * 16b entry code does and jumps off to the real startup_32. + */ + cli + wbinvd + + /* + * The %ebx provided is not terribly useful since it is the physical + * address of tb_trampoline_start and not the base of the image. + * Use pa_real_mode_base, which is fixed up, to get a run time + * base register to use for offsets to location that do not have + * pa_ symbols. + */ + movl $pa_real_mode_base, %ebx + + LOCK_AND_LOAD_REALMODE_ESP lock_pa=1 + + lgdt tr_gdt(%ebx) + lidt tr_idt(%ebx) + + movw $__KERNEL_DS, %dx # Data segment descriptor + + /* Jump to where the 16b code would have jumped */ + ljmpl $__KERNEL32_CS, $pa_startup_32 +SYM_CODE_END(sl_trampoline_start32) +#endif + .balign 4 SYM_CODE_START(startup_32) movl %edx, %ss From patchwork Thu Dec 19 19:42:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852151 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 914211FAC55; Thu, 19 Dec 2024 19:57:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638236; cv=none; b=bM6NwGzLwX/aGZJPMFLeip86UPZq/Ja+Fz5rwOUi6lqARaEpwwKyLDWwGqtyBCIuBW1WfOfZEB8qga/hPILz+nND7IliZc4jOT0vWliZMb8fHpT4EUFt8Z8LoWoEi4x2yu2C8vzc5GvmHjYHnGylti3/GikhL09mYnSd+VALl/o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638236; c=relaxed/simple; bh=dmpG2F8Lnuu13JXpepntJ4OBAClHR/9eu6NZeWsDR3o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IEjd7k5EYMuEH9J4G7NKiYSnQJYDqzC5Id2GjM/z6f+iOps81wHKBMsLaWN5HUzFYgNIMl0PQK0alWpMyWvVCTIn2Er1vAlRhJCqm3RpatylaVTRy+2bykVDsv6CAbP7fkpGBz8aGmnX/xvgTHrGOJRZVl9oUVTLcn6ENFnyLmo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=DWnzpxGd; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="DWnzpxGd" Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMkTS007019; Thu, 19 Dec 2024 19:55:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=hi5Cv i6W0EnpZmrRTj9AQy6lu91T7AQBkJhdBnD37Bo=; b=DWnzpxGdjIu2O13RVUzMn kDqTp9NdAbsZdKhwKTpUFCd2MD0a8qbtwxU7SPgynLd7Qw5lxbgPRkIFx0mnJ8dV 8m8rZfGXRttHdDlKEw9i6zYlvhQsIy2l1enH5Dl+0YVKnqgzPZVzzhM/mmOWBpeI xllv7DpAQ9zj4+dy/ajpCdnz1iE+G2WG9nx/7qldOh1UjFiEBPOdE5arL4BBFGpf G1AY8a/SRIXbDNR6ZOh4KNnuuqK2kNejYzqvv8l0l11QPZz9GeIhdJuvOB7KJRc8 lOLWVt7jPByD8M8VeR/XM1E1Q8UDWq0Nb54ZnyI3ds+rv/InA9gHZCjVljCGzAd5 w== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h1w9krqe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:55:51 +0000 (GMT) Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIsvoN032785; Thu, 19 Dec 2024 19:55:50 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fhvnct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:55:50 +0000 Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJtnth014303; Thu, 19 Dec 2024 19:55:49 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fhvnbf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:55:49 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 12/19] kexec: Secure Launch kexec SEXIT support Date: Thu, 19 Dec 2024 11:42:09 -0800 Message-Id: <20241219194216.152839-13-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: sscU-uA9FJgmhahSxoQ8ovxm2ztcs6-H X-Proofpoint-ORIG-GUID: sscU-uA9FJgmhahSxoQ8ovxm2ztcs6-H Prior to running the next kernel via kexec, the Secure Launch code closes down private SMX resources and does an SEXIT. This allows the next kernel to start normally without any issues starting the APs etc. Signed-off-by: Ross Philipson --- arch/x86/kernel/slaunch.c | 72 +++++++++++++++++++++++++++++++++++++++ kernel/kexec_core.c | 4 +++ 2 files changed, 76 insertions(+) diff --git a/arch/x86/kernel/slaunch.c b/arch/x86/kernel/slaunch.c index 5c54288ce980..c828d46f3271 100644 --- a/arch/x86/kernel/slaunch.c +++ b/arch/x86/kernel/slaunch.c @@ -522,3 +522,75 @@ void __init slaunch_setup_txt(void) pr_info("Intel TXT setup complete\n"); } + +static inline void smx_getsec_sexit(void) +{ + asm volatile ("getsec\n" + : : "a" (SMX_X86_GETSEC_SEXIT)); +} + +/* + * Used during kexec and on reboot paths to finalize the TXT state + * and do an SEXIT exiting the DRTM and disabling SMX mode. + */ +void slaunch_finalize(int do_sexit) +{ + u64 one = TXT_REGVALUE_ONE, val; + void __iomem *config; + + if (!slaunch_is_txt_launch()) + return; + + config = ioremap(TXT_PRIV_CONFIG_REGS_BASE, TXT_NR_CONFIG_PAGES * + PAGE_SIZE); + if (!config) { + pr_emerg("Error SEXIT failed to ioremap TXT private reqs\n"); + return; + } + + /* Clear secrets bit for SEXIT */ + memcpy_toio(config + TXT_CR_CMD_NO_SECRETS, &one, sizeof(one)); + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + /* Unlock memory configurations */ + memcpy_toio(config + TXT_CR_CMD_UNLOCK_MEM_CONFIG, &one, sizeof(one)); + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + /* Close the TXT private register space */ + memcpy_toio(config + TXT_CR_CMD_CLOSE_PRIVATE, &one, sizeof(one)); + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + /* + * Calls to iounmap are not being done because of the state of the + * system this late in the kexec process. Local IRQs are disabled and + * iounmap causes a TLB flush which in turn causes a warning. Leaving + * thse mappings is not an issue since the next kernel is going to + * completely re-setup memory management. + */ + + /* Map public registers and do a final read fence */ + config = ioremap(TXT_PUB_CONFIG_REGS_BASE, TXT_NR_CONFIG_PAGES * + PAGE_SIZE); + if (!config) { + pr_emerg("Error SEXIT failed to ioremap TXT public reqs\n"); + return; + } + + memcpy_fromio(&val, config + TXT_CR_E2STS, sizeof(val)); + + pr_emerg("TXT clear secrets bit and unlock memory complete.\n"); + + if (!do_sexit) + return; + + if (smp_processor_id() != 0) + panic("Error TXT SEXIT must be called on CPU 0\n"); + + /* In case SMX mode was disabled, enable it for SEXIT */ + cr4_set_bits(X86_CR4_SMXE); + + /* Do the SEXIT SMX operation */ + smx_getsec_sexit(); + + pr_info("TXT SEXIT complete.\n"); +} diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index c0caa14880c3..53d5ae8326a3 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -1045,6 +1046,9 @@ int kernel_kexec(void) cpu_hotplug_enable(); pr_notice("Starting new kernel\n"); machine_shutdown(); + + /* Finalize TXT registers and do SEXIT */ + slaunch_finalize(1); } kmsg_dump(KMSG_DUMP_SHUTDOWN); From patchwork Thu Dec 19 19:42:11 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852150 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFF7E1FCFFB; Thu, 19 Dec 2024 19:57:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638254; cv=none; b=otQ2NWFFcSV+pU/tp2+BeH/CeAw8gyYqF1oINidVe9FXcmLaOD4hBg0cR0I5cBiUnJhtoU6fL/oy2e4QVgeiefe91g3iKFZ2HZqKnU0JlEw9dWMqzl4swi+r1PTqjjfh2BwmgXhW/TMTK0z95BU4VTr1tX8lIeMCoXOqK3TGY2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638254; c=relaxed/simple; bh=QTOUJugONytRA9Yfke3RAnHred44LDbOZrJbHj/o2hg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=V8JpeZ7T5DdlClYmN9RwCN4BZryKO+IYCfCtmTX4ML45Cge9kxh62JJcySYjrwfyQl7oKkrwlZbv0k8SmzGDyLGem4mjSbGWlfmvpW4fXRnn9ty6wx2bC6igf4GzlQBXh7Z9dtNSc56+l//ctcuH/mSX0Uw0rpSSrMc3dAibVmA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=lilhofyc; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="lilhofyc" Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMiVK030947; Thu, 19 Dec 2024 19:56:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=ChunI 277u1t8ofdws0fBQoZh27ftUd8UsKlRxDb0DKI=; b=lilhofycp3ulQ9RFZCVjj YIp032J7vZrfPE0fniQ+XuQK2Lvom7vwhE0qDmB7q/BoiHQgA9QPZNxLsaB8JOTs euooMV2mC+KUeQRmr4aLDleCq2g21ON6dRm9/ahsKvPRceZg7xswX0/mDySJD0og AUA3oidnPVCAFQ4t1vCcU0mVtsyPCrmMm72tA7ufE2WD2/pM0yA1nk806wJSvujp q2hL/yGx0vKjhD+wSdCTj5QSW+KdqJDB7/miMyKgPjkqKmDGZN6qrsZp+hmE6gK3 hx08jAwzUiy+OU/LfbTb0UTM64tpiASFiNdYMETIHB/xWE0a6uZlYiEuSnD0/Dyu Q== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h2jtc1bj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:56:09 +0000 (GMT) Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIZgmv032714; Thu, 19 Dec 2024 19:56:07 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fhvnpr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:07 +0000 Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJtD8Y012020; Thu, 19 Dec 2024 19:56:06 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fhvnnm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:06 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 14/19] tpm, tpm_tis: Close all localities Date: Thu, 19 Dec 2024 11:42:11 -0800 Message-Id: <20241219194216.152839-15-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: yaKvFm7rBjxnR6jX4HmaILm9XrcMLyOi X-Proofpoint-ORIG-GUID: yaKvFm7rBjxnR6jX4HmaILm9XrcMLyOi From: "Daniel P. Smith" There are environments, for example, those that comply with the TCG D-RTM specification that requires the TPM to be left in locality 2. Prepare kernel for such environments by closing all the localities. Signed-off-by: Daniel P. Smith Signed-off-by: Ross Philipson Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm_tis_core.c | 11 ++++++++++- include/linux/tpm.h | 6 ++++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index fdef214b9f6b..c58f360fb4a4 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -1104,7 +1104,7 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq, u32 intmask; u32 clkrun_val; u8 rid; - int rc, probe; + int rc, probe, i; struct tpm_chip *chip; chip = tpmm_chip_alloc(dev, &tpm_tis); @@ -1166,6 +1166,15 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq, goto out_err; } + /* + * There are environments, for example, those that comply with the TCG D-RTM + * specification that requires the TPM to be left in Locality 2. + */ + for (i = 0; i <= TPM_MAX_LOCALITY; i++) { + if (check_locality(chip, i)) + tpm_tis_relinquish_locality(chip, i); + } + /* Take control of the TPM's interrupt hardware and shut it off */ rc = tpm_tis_read32(priv, TPM_INT_ENABLE(priv->locality), &intmask); if (rc < 0) diff --git a/include/linux/tpm.h b/include/linux/tpm.h index 20a40ade8030..c5a4a2d7dd15 100644 --- a/include/linux/tpm.h +++ b/include/linux/tpm.h @@ -147,6 +147,12 @@ struct tpm_chip_seqops { */ #define TPM2_MAX_CONTEXT_SIZE 4096 +/* + * The maximum locality (0 - 4) for a TPM, as defined in section 3.2 of the + * Client Platform Profile Specification. + */ +#define TPM_MAX_LOCALITY 4 + struct tpm_chip { struct device dev; struct device devs; From patchwork Thu Dec 19 19:42:12 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852153 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFFB31B4F23; Thu, 19 Dec 2024 19:56:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.165.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638201; cv=none; b=tTz9yrrgjlYZM1HQz9Sou/nxHcJRKje9xLbxmf3C5uccLF2tuehYizO2qVGJFIG1NGyijOglwRSM2vbrtaTI8ztRtrsPrNXzQk9fe/mMOz0A3pUvyGJ4dT+fHh7DFEPGULYV4LQYquYguqB26OldMtkz5AqAMSaZc/jvUV7DcFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638201; c=relaxed/simple; bh=Nvqwo2igdYCQOyd5loE1ZK0MPF4w3/+f1D0ssOCeOw8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=eEFi8RETM4TqsSpdzaCMm1p8IFQEVHLES6zJwYGCEU7chYdeSJT1N1mUP4p0sDfAjM+3d/FZu+hygNRaMHsO5AgEB9o5v5DRefa6D3MIeMbnklmUGdJlLKe8y3mbaO2f0wITxKSMf1YQReQfdI88oLr1McaWnAQGbUoaCKioFIs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=G2IDzniH; arc=none smtp.client-ip=205.220.165.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="G2IDzniH" Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMuJW007252; Thu, 19 Dec 2024 19:56:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=OBOgf QOjyP8Bq9tvrcNT5coBWN82Ffz8eLAs0soGdwM=; b=G2IDzniHbpUKiyZzvadjT T8i/0iUFdaU3EvQQCXJUpYUwMIvnQygIww7z55tu9X74A4NZCiN/hy9kx5Bcaix/ aKuNyzzAyLWkkAPYTG3a5dRk/PlcKwKbmiDUwfhPShUmrk21ZESIwH75ODXrDl73 5hh3TjjUl5w37c+8PInhnBytQzguYx4FzzjoUk+WpdSgns5zkMiLo21ayuBPvZz9 hNMK+LagJQ8vOnP3xYiQ4tJ6er4Iklu1gMxqDimnqEzl5wfi/hSzFKkp2Qknlcnc 32aT+earb1Hnyk1ZW9R0ESJZUhLKBfD6rrDPuKTHC6t56rjDOv5/XKIdnseGWA+v g== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h1w9krrv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:56:18 +0000 (GMT) Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJJUnte006411; Thu, 19 Dec 2024 19:56:17 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fcgnmn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:17 +0000 Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJuGKo022252; Thu, 19 Dec 2024 19:56:16 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fcgnhy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:16 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 15/19] tpm, tpm_tis: Address positive localities in tpm_tis_request_locality() Date: Thu, 19 Dec 2024 11:42:12 -0800 Message-Id: <20241219194216.152839-16-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 malwarescore=0 bulkscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: YTKsKTah_LNHirE9K_dc1quWKDM5dmy3 X-Proofpoint-ORIG-GUID: YTKsKTah_LNHirE9K_dc1quWKDM5dmy3 From: "Daniel P. Smith" Validate that the input locality is within the correct range, as specified by TCG standards, and increase the locality count also for the positive localities. Signed-off-by: Daniel P. Smith Signed-off-by: Ross Philipson Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm_tis_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index c58f360fb4a4..c86100ad743a 100644 --- a/drivers/char/tpm/tpm_tis_core.c +++ b/drivers/char/tpm/tpm_tis_core.c @@ -234,10 +234,13 @@ static int tpm_tis_request_locality(struct tpm_chip *chip, int l) struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev); int ret = 0; + if (l < 0 || l > TPM_MAX_LOCALITY) + return -EINVAL; + mutex_lock(&priv->locality_count_mutex); if (priv->locality_count == 0) ret = __tpm_tis_request_locality(chip, l); - if (!ret) + if (ret >= 0) priv->locality_count++; mutex_unlock(&priv->locality_count_mutex); return ret; From patchwork Thu Dec 19 19:42:14 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852152 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 523171B4F25; Thu, 19 Dec 2024 19:57:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.177.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638222; cv=none; b=YPm+9cySvn+lHgwbycVlM1WYCxdEtfBnsQo0/8z34Oz91yM+sxqs9Gbi+gdN+EVvYfBaZt95h5djIC92ubt4/SLT8pp9eyOvU8AZzaHb+MW1IAX2Td8I94TCt3FaGTEYBX19ko/7AniXHXWG82Vmq7UimGlkq3sh0qCcIQJyw9E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638222; c=relaxed/simple; bh=+PmIuyNK+4awhsE4aojbYix6PiS1trn5xAQYLYmeZhE=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=LJlv0TNJUNwYCTi1h0dEFj7iP8RvPtdIexvkN0XkL5hCntxAcbZKxMfGoWaAfjjyQHk8BHCsbC1UYkF8iTGBR+hIxIrsMGArl+TFCb6XR31YQOr9CmWK5i9b+wgeGfES1q0yny1zbWevW5zsZd95Y1PqJ3QLTnKgOb05E6Osu8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=YrpXWu8Z; arc=none smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="YrpXWu8Z" Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMhnX029767; Thu, 19 Dec 2024 19:56:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=CowCr Kkz6qMYC8ITtUUSe4qTq9Lm5ZaWaqeyPEIlDy0=; b=YrpXWu8ZI605v7bujomOT znCzInbQ53qzezkc4M7Xytpbp2t8P3R8nU7TWup/rh7RrBStS9CcxYAVB28Mb1tD vOIA5OTu1dPa7dVI6emk87p4MM0+0kF2+sTiU9We8di7cwEidmf7Ypr870zcj1zo 9uOKtZN2Z8+KRcQwseeIPr/h3bMuUSj4BlwJEmtUyACHSl58DAeSs8FT0pa+Dexy hdmJW+PEFppXgKrVtCyLIEcggZcnLqmhpxNldzSoLJw/bRiXSmsV/j1dclGTCSbP xEup93EiwTJNer/XKYbLLGbkbCdhQD2RzLs9ten4toWi6eOtDzeUrywDTqNdHttB g== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h22cuvbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:56:36 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIZOm8010974; Thu, 19 Dec 2024 19:56:35 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbfqf8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:35 +0000 Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJuYQX022410; Thu, 19 Dec 2024 19:56:34 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbfqd3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:34 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 17/19] tpm, sysfs: Show locality used by kernel Date: Thu, 19 Dec 2024 11:42:14 -0800 Message-Id: <20241219194216.152839-18-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: 2OX8Hz0Oa7BCTVR1CKrDoVB313-5zefT X-Proofpoint-ORIG-GUID: 2OX8Hz0Oa7BCTVR1CKrDoVB313-5zefT Expose the locality used by the kernel to sysfs. Signed-off-by: Ross Philipson Signed-off-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-sysfs.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c index 94231f052ea7..2da5857e223b 100644 --- a/drivers/char/tpm/tpm-sysfs.c +++ b/drivers/char/tpm/tpm-sysfs.c @@ -309,6 +309,14 @@ static ssize_t tpm_version_major_show(struct device *dev, } static DEVICE_ATTR_RO(tpm_version_major); +static ssize_t locality_show(struct device *dev, struct device_attribute *attr, char *buf) +{ + struct tpm_chip *chip = to_tpm_chip(dev); + + return sprintf(buf, "%u\n", chip->kernel_locality); +} +static DEVICE_ATTR_RO(locality); + #ifdef CONFIG_TCG_TPM2_HMAC static ssize_t null_name_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -336,6 +344,7 @@ static struct attribute *tpm1_dev_attrs[] = { &dev_attr_durations.attr, &dev_attr_timeouts.attr, &dev_attr_tpm_version_major.attr, + &dev_attr_locality.attr, NULL, }; @@ -344,6 +353,7 @@ static struct attribute *tpm2_dev_attrs[] = { #ifdef CONFIG_TCG_TPM2_HMAC &dev_attr_null_name.attr, #endif + &dev_attr_locality.attr, NULL }; From patchwork Thu Dec 19 19:42:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 852149 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10D8B1BD9D3; Thu, 19 Dec 2024 19:58:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.177.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638295; cv=none; b=NDMMM4xq0o1Wljr30Rb2E6mfyf4/1rfYOEnn3YSlsWtE8tq99dlh2McN9sDlT89jfBdaUBm6gWBEVbWgwKozbqMIcKBBJw6IqsFwPTlvSAsaDz/8vdhjGHIyXI7IsiX8Gng2ZzcFc1rsJ/MiITSX8mkU66RHhQ39iNgNtYJ93zk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734638295; c=relaxed/simple; bh=HKup6Twxuzvh9My98TZ9Rm5s01uCW6W1C5fvM8b8NC0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=GGHUKF4hihZZuH59M0RbP/EHD0ulHo9J+I40s01IY0Lm5dPfJi9y2KbIRFhW1NmPOHelYeGChuhAv77hp+lRJehWStG/x2te607bcP3bFK8azCXOTlWl18l/SawQyCGHHMHpggIwGD3kZTzQYKuC5p4PwSiAMq+4nYjUtEU7hjM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=EDrL977f; arc=none smtp.client-ip=205.220.177.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="EDrL977f" Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJIMh9G029748; Thu, 19 Dec 2024 19:56:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=CAR2X DvMpSDNgRI4ba9QodPpLgYuOG3w5cBkcUBDh0g=; b=EDrL977flAIHAN2R2MTGb r0LSdAUHvjZxGmUdu+JcB2XC7CumxXPw6SbNh6/bmnL4HJbdh6UPhItXq3Vn7iTU k4MEpidVnaEMZ6d3Mm7fVVwSBOvjAyuNjwvfYlvry46CHDXq0CtzCSP//JZbFFjE wtbvaJeij0hJux2qbW1uXi1DNjHEsT9aR/FkN9rj2B0d2t1OTzl+jzmbNAeQV3tf 6wMiF/lGGhCdfNuuViTPnl391YL6lqd6XppdrocGQem7kdVAMwWdVAZUY43YlVFm W50ZICD7oSudfinCgskpbUo7zcaiGexE4CgCM6zY63dvZZzUtCKWdrTHSR80ecK7 w== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43h22cuvc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Dec 2024 19:56:51 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4BJJHs6P018324; Thu, 19 Dec 2024 19:56:50 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbvwk8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:50 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4BJJunsH002858; Thu, 19 Dec 2024 19:56:49 GMT Received: from bur-virt-x6-2-100.us.oracle.com (bur-virt-x6-2-100.us.oracle.com [10.153.92.40]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43h0fbvwgm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Dec 2024 19:56:49 +0000 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-foundation.org Cc: ross.philipson@oracle.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, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Subject: [PATCH v12 19/19] x86/efi: EFI stub DRTM launch support for Secure Launch Date: Thu, 19 Dec 2024 11:42:16 -0800 Message-Id: <20241219194216.152839-20-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20241219194216.152839-1-ross.philipson@oracle.com> References: <20241219194216.152839-1-ross.philipson@oracle.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-19_09,2024-12-19_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 bulkscore=0 suspectscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2412190158 X-Proofpoint-GUID: n26lGIjuWLBeE41cJiA9lwyEURTykH58 X-Proofpoint-ORIG-GUID: n26lGIjuWLBeE41cJiA9lwyEURTykH58 This support allows the DRTM launch to be initiated after an EFI stub launch of the Linux kernel is done. This is accomplished by providing a handler to jump to when a Secure Launch is in progress. This has to be called after the EFI stub does Exit Boot Services. Signed-off-by: Ross Philipson Reviewed-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/efistub.h | 8 +++ drivers/firmware/efi/libstub/x86-stub.c | 94 +++++++++++++++++++++++++ 2 files changed, 102 insertions(+) diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h index 76e44c185f29..f63e5197ea53 100644 --- a/drivers/firmware/efi/libstub/efistub.h +++ b/drivers/firmware/efi/libstub/efistub.h @@ -135,6 +135,14 @@ void efi_set_u64_split(u64 data, u32 *lo, u32 *hi) *hi = upper_32_bits(data); } +static inline +void efi_set_u64_form(u32 lo, u32 hi, u64 *data) +{ + u64 upper = hi; + + *data = lo | upper << 32; +} + /* * Allocation types for calls to boottime->allocate_pages. */ diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c index 188c8000d245..403a191c31cc 100644 --- a/drivers/firmware/efi/libstub/x86-stub.c +++ b/drivers/firmware/efi/libstub/x86-stub.c @@ -9,6 +9,8 @@ #include #include #include +#include +#include #include #include @@ -922,6 +924,93 @@ static efi_status_t efi_decompress_kernel(unsigned long *kernel_entry) return efi_adjust_memory_range_protection(addr, kernel_text_size); } +#if (IS_ENABLED(CONFIG_SECURE_LAUNCH)) +static bool efi_secure_launch_update_boot_params(struct slr_table *slrt, + struct boot_params *boot_params) +{ + struct slr_entry_intel_info *txt_info; + struct slr_entry_policy *policy; + bool updated = false; + int i; + + txt_info = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_INTEL_INFO); + if (!txt_info) + return false; + + txt_info->boot_params_addr = (u64)boot_params; + + policy = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_ENTRY_POLICY); + if (!policy) + return false; + + for (i = 0; i < policy->nr_entries; i++) { + if (policy->policy_entries[i].entity_type == SLR_ET_BOOT_PARAMS) { + policy->policy_entries[i].entity = (u64)boot_params; + updated = true; + break; + } + } + + /* + * If this is a PE entry into EFI stub the mocked up boot params will + * be missing some of the setup header data needed for the second stage + * of the Secure Launch boot. + */ + if (image) { + struct setup_header *hdr = (struct setup_header *)((u8 *)image->image_base + + offsetof(struct boot_params, hdr)); + u64 cmdline_ptr; + + boot_params->hdr.setup_sects = hdr->setup_sects; + boot_params->hdr.syssize = hdr->syssize; + boot_params->hdr.version = hdr->version; + boot_params->hdr.loadflags = hdr->loadflags; + boot_params->hdr.kernel_alignment = hdr->kernel_alignment; + boot_params->hdr.min_alignment = hdr->min_alignment; + boot_params->hdr.xloadflags = hdr->xloadflags; + boot_params->hdr.init_size = hdr->init_size; + boot_params->hdr.kernel_info_offset = hdr->kernel_info_offset; + efi_set_u64_form(boot_params->hdr.cmd_line_ptr, boot_params->ext_cmd_line_ptr, + &cmdline_ptr); + boot_params->hdr.cmdline_size = strlen((const char *)cmdline_ptr); + } + + return updated; +} + +static void efi_secure_launch(struct boot_params *boot_params) +{ + struct slr_entry_dl_info *dlinfo; + efi_guid_t guid = SLR_TABLE_GUID; + dl_handler_func handler_callback; + struct slr_table *slrt; + + /* + * The presence of this table indicated a Secure Launch + * is being requested. + */ + slrt = (struct slr_table *)get_efi_config_table(guid); + if (!slrt || slrt->magic != SLR_TABLE_MAGIC) + return; + + /* + * Since the EFI stub library creates its own boot_params on entry, the + * SLRT and TXT heap have to be updated with this version. + */ + if (!efi_secure_launch_update_boot_params(slrt, boot_params)) + return; + + /* Jump through DL stub to initiate Secure Launch */ + dlinfo = slr_next_entry_by_tag(slrt, NULL, SLR_ENTRY_DL_INFO); + + handler_callback = (dl_handler_func)dlinfo->dl_handler; + + handler_callback(&dlinfo->bl_context); + + unreachable(); +} +#endif + static void __noreturn enter_kernel(unsigned long kernel_addr, struct boot_params *boot_params) { @@ -1049,6 +1138,11 @@ void __noreturn efi_stub_entry(efi_handle_t handle, goto fail; } +#if (IS_ENABLED(CONFIG_SECURE_LAUNCH)) + /* If a Secure Launch is in progress, this never returns */ + efi_secure_launch(boot_params); +#endif + /* * Call the SEV init code while still running with the firmware's * GDT/IDT, so #VC exceptions will be handled by EFI.