Re: [PATCH v7 02/13] Documentation/x86: Secure Launch kernel documentation
Hi Alyssa, apologies for the late response. On 11/12/23 13:07, Alyssa Ross wrote: +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. I'm somewhat familiar with this area, but not massively (so probably the sort of person this documentation is aimed at!), and this was the only section of the documentation I had trouble understanding. The thing that confused me was that the first time I read this, I was thinking that a hashing assessment would be comparing the generated hash to a baked-in known good hash, simliar to how e.g. a verity root hash might be specified on the kernel command line, baked in to the OS image. This made me wonder why it wasn't considered to be adjudicated during assessment. Upon reading it a second time, I now understand that what it's actually talking about is generating a hash, but not comparing it automatically against anything, and making it available for external adjudication somehow. I don't know if the approach I first thought of is used in early boot at all, but it might be worth contrasting the cryptographic hashing assessment described here with it, because I imagine that I'm not going to be the only reader who's more used to thinking about integrity slightly later in the boot process where adjudicating based on a static hash is common, and who's mind is going to go to that when they read about a "cryptographic hashing assessment". The scenario that first came to mind for you, specifically the verity root hash, is in fact a form of signature checking assessment. A signature is nothing more than saying here is a hash with provenance that is enforced by the measuring entity. For a PKI signature, e.g. UEFI Secure Boot, the provenance is confirming that the encrypted portion of the signature can be decrypted using the CA public key. For the case of dm-verity, the provenance of the hash is its source, that it came from the command line. If you consider the consequences presented for a signature checking assessment, one should see the same issues with dm-verity: 1) any logic in the kernel, intended or injected, could tamper with the validation of the hash, 2) there is no evidence of each block hashed into the final hash that is assessed, and 3) the system is responsible to ensure only the correct hash has been provided on the command line. Another way to consider the above, there are always two actions for assessing integrity, measurement and assessment. When both actions are delegated to a single entity along with a mechanism to provide the known good, this is a signature checking assessment. When these two actions are delegated to two separate entities, this is a cryptographic hashing assessment. In TCG parlance, the former is a Root of Trust for Verification (RTV) chain and the latter is a Root of Trust for Measurement (RTM) chain. And to clarify the example provided by Ross in using the TPM seal method. This is a cryptographic hashing assessment, as the two functions are done by separate entities. The software makes the measurements while the TPM makes the assessment. In
Re: [PATCH v7 02/13] Documentation/x86: Secure Launch kernel documentation
On 11/12/23 10:07 AM, Alyssa Ross wrote: +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. I'm somewhat familiar with this area, but not massively (so probably the sort of person this documentation is aimed at!), and this was the only section of the documentation I had trouble understanding. The thing that confused me was that the first time I read this, I was thinking that a hashing assessment would be comparing the generated hash to a baked-in known good hash, simliar to how e.g. a verity root hash might be specified on the kernel command line, baked in to the OS image. This made me wonder why it wasn't considered to be adjudicated during assessment. Upon reading it a second time, I now understand that what it's actually talking about is generating a hash, but not comparing it automatically against anything, and making it available for external adjudication somehow. Yes there is nothing baked into an image in the way we currently use is. I take what you call a hashing assessment to be what we would call remote attestation where an independent agent assesses the state of the measured launch. This is indeed one of the primary use cases. There is another use case closer to the baked in one where secrets on the system are sealed to the TPM using a known good PCR configuration. Only by launching and attaining that known good state can the secrets be unsealed. I don't know if the approach I first thought of is used in early boot at all, but it might be worth contrasting the cryptographic hashing assessment described here with it, because I imagine that I'm not going to be the only reader who's more used to thinking about integrity slightly later in the boot process where adjudicating based on a static hash is common, and who's mind is going to go to that when they read about a "cryptographic hashing assessment". The rest of the documentation was easy to understand and very helpful to understanding system launch integrity. Thanks! I am glad it was helpful. We will revisit the section that caused confusion and see if we can make it clearer. Thank you, Ross
Re: [PATCH v7 02/13] Documentation/x86: Secure Launch kernel documentation
> +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. I'm somewhat familiar with this area, but not massively (so probably the sort of person this documentation is aimed at!), and this was the only section of the documentation I had trouble understanding. The thing that confused me was that the first time I read this, I was thinking that a hashing assessment would be comparing the generated hash to a baked-in known good hash, simliar to how e.g. a verity root hash might be specified on the kernel command line, baked in to the OS image. This made me wonder why it wasn't considered to be adjudicated during assessment. Upon reading it a second time, I now understand that what it's actually talking about is generating a hash, but not comparing it automatically against anything, and making it available for external adjudication somehow. I don't know if the approach I first thought of is used in early boot at all, but it might be worth contrasting the cryptographic hashing assessment described here with it, because I imagine that I'm not going to be the only reader who's more used to thinking about integrity slightly later in the boot process where adjudicating based on a static hash is common, and who's mind is going to go to that when they read about a "cryptographic hashing assessment". The rest of the documentation was easy to understand and very helpful to understanding system launch integrity. Thanks! signature.asc Description: PGP signature
[PATCH v7 02/13] Documentation/x86: Secure Launch kernel documentation
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 | 320 ++ .../secure_launch_details.rst | 584 ++ .../secure_launch_overview.rst| 226 +++ 5 files changed, 1142 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 59f8fc106cb0..56e31fb3d91f 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -19,3 +19,4 @@ Security Documentation digsig landlock secrets/index + launch-integrity/index diff --git a/Documentation/security/launch-integrity/index.rst b/Documentation/security/launch-integrity/index.rst new file mode 100644 index ..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 ..68a415aec545 --- /dev/null +++ b/Documentation/security/launch-integrity/principles.rst @@ -0,0 +1,320 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright © 2019-2023 Daniel P. Smith + +=== +System Launch Integrity +=== + +:Author: Daniel P. Smith +:Date: October 2023 + +This document serves to establish a common understanding of what is system +launch, the integrity concern for system launch, and why using a Root of Trust +(RoT) from a Dynamic Launch may be desired. Throughout this document +terminology from the Trusted Computing Group (TCG) and National Institute for +Science and Technology (NIST) is used to ensure a 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, but in fact most +modern processors support two methods to launch the system. To provide clarity +a common definition of a system launch should be established. This definition +is that a 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 to launch a system, these two +types 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 being 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
