Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On 5/6/23 04:48, Bagas Sanjaya wrote: On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: += +System Launch Integrity documentation += + +.. toctree:: By convention, doc toctree have 2-level depth (only page title and first-level headings are visible). You may consider adding `:maxdepth: 2` option. Will do. diff --git a/Documentation/security/launch-integrity/principles.rst b/Documentation/security/launch-integrity/principles.rst new file mode 100644 index 000..73cf063 --- /dev/null +++ b/Documentation/security/launch-integrity/principles.rst @@ -0,0 +1,313 @@ +=== +System Launch Integrity +=== + +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. Through out this document +terminology from the Trusted Computing Group (TCG) and National Institue for +Science and Technology (NIST) is used to ensure a vendor nutrual 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 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 are a subset of these mechanisms, commonly +referred to as security mechanisms, that are present to help ensure the system +produces the expected result or at least detect the potential of an unexpected +result may have happened. 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 and for +trusted mechanism enables for 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
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On 6/16/23 12:54, Matthew Garrett wrote: On Fri, Jun 16, 2023 at 12:44:27PM -0400, Daniel P. Smith wrote: On 5/12/23 06:47, Matthew Garrett wrote: On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: +Secure Launch does not interoperate with KASLR. If possible, the MLE should be +built with KASLR disabled:: Why does Secure Launch not interoperate with KASLR? Re: IOMMUs Until the IOMMU driver comes online, memory is protected by the PMRs regions requested by the Preamble (pre-launch code) in accordance with Intel TXT specifications and configured by the ACM. The KASLR randomizer will run before the IOMMU driver is able to come online and ensure frames used by the kernel are protected as well as frames that a driver may registered in a BAR are not blocked. This seems unfortunate. Presumably we're not able to modify the PMRs at this point? This also seems like a potential issue for IOMMU config in general - the presumption is that the firmware should be configuring the IOMMU in such a way that DMA-capable devices can't attack the firmware while we're in the boot environment, and if KASLR is leaving a window there then it seems like we'd need to fix that? While unfortunate, it is a bit of the nature of the problem KASLR is attempting to address. If you know in advance where kernel pages are going to live and the frames that will be used for DMA, then have you not defeated the purpose of the randomization? As for the firmware use of the IOMMU, I am fairly certain those tables will get invalidated by the ACM when it is setting up the PMRs. +It is recommended that no other command line options should be set to override +the defaults above. What happens if they are? Does doing so change the security posture of the system? If so, will the measurements be different in a way that demonstrates the system is in an insecure state? In an early version of the patch series this was enforced when turning on Secure Launch, but concerns were raised over this approach and was asked to allow the user to be able to shoot themselves in the foot. Overriding these values could render either an insecure state and/or an unstable system. If we're in an insecure state, is that something that would show up in the form of different measurements? Yes, you would get a different measurement for the commandline. If you are thinking in terms of attestation, I would expect that the attestation measurement db would have a record for an acceptable commandline and would determine the system to be in an unknown state if it did not match. While the idea could be explored to create measurements based on configurations of kernel subsystems, this would likely entail instrumentation in those subsystems to assert a measurement to their configuration. Maybe IMA could cover something like this? It would definitely enable the ability to make deeper assessments about the state of a system, but I think this is out of the scope of what Secure Launch is attempting to do. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On Fri, Jun 16, 2023 at 12:44:27PM -0400, Daniel P. Smith wrote: > > On 5/12/23 06:47, Matthew Garrett wrote: > > On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > > > +Secure Launch does not interoperate with KASLR. If possible, the MLE > > > should be > > > +built with KASLR disabled:: > > > > Why does Secure Launch not interoperate with KASLR? > > > > Re: IOMMUs > > Until the IOMMU driver comes online, memory is protected by the PMRs regions > requested by the Preamble (pre-launch code) in accordance with Intel TXT > specifications and configured by the ACM. The KASLR randomizer will run > before the IOMMU driver is able to come online and ensure frames used by the > kernel are protected as well as frames that a driver may registered in a BAR > are not blocked. This seems unfortunate. Presumably we're not able to modify the PMRs at this point? This also seems like a potential issue for IOMMU config in general - the presumption is that the firmware should be configuring the IOMMU in such a way that DMA-capable devices can't attack the firmware while we're in the boot environment, and if KASLR is leaving a window there then it seems like we'd need to fix that? > > > +It is recommended that no other command line options should be set to > > > override > > > +the defaults above. > > > > What happens if they are? Does doing so change the security posture of > > the system? If so, will the measurements be different in a way that > > demonstrates the system is in an insecure state? > > > > In an early version of the patch series this was enforced when turning on > Secure Launch, but concerns were raised over this approach and was asked to > allow the user to be able to shoot themselves in the foot. Overriding these > values could render either an insecure state and/or an unstable system. If we're in an insecure state, is that something that would show up in the form of different measurements? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On 5/12/23 06:47, Matthew Garrett wrote: On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: +Secure Launch does not interoperate with KASLR. If possible, the MLE should be +built with KASLR disabled:: Why does Secure Launch not interoperate with KASLR? Re: IOMMUs Until the IOMMU driver comes online, memory is protected by the PMRs regions requested by the Preamble (pre-launch code) in accordance with Intel TXT specifications and configured by the ACM. The KASLR randomizer will run before the IOMMU driver is able to come online and ensure frames used by the kernel are protected as well as frames that a driver may registered in a BAR are not blocked. +It is recommended that no other command line options should be set to override +the defaults above. What happens if they are? Does doing so change the security posture of the system? If so, will the measurements be different in a way that demonstrates the system is in an insecure state? In an early version of the patch series this was enforced when turning on Secure Launch, but concerns were raised over this approach and was asked to allow the user to be able to shoot themselves in the foot. Overriding these values could render either an insecure state and/or an unstable system. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On Thu, May 04 2023 at 14:50, Ross Philipson wrote: > +KASLR Configuration > +--- > + > +Secure Launch does not interoperate with KASLR. If possible, the MLE should > be > +built with KASLR disabled:: Why? > + "Processor type and features" --> > + "Build a relocatable kernel" --> > + "Randomize the address of the kernel image (KASLR) [ ]" > + > +This unsets the Kconfig value CONFIG_RANDOMIZE_BASE. > + > +If not possible, KASLR must be disabled on the kernel command line when doing > +a Secure Launch as follows:: > + > + nokaslr So what happens if KASLR is enabled in Kconfig and not disabled on the command line? > +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 PMR's [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. Is any of this validated and are proper warnings emitted or is it just recommended and left to the user to do the right thing? Thanks, tglx ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > +Secure Launch does not interoperate with KASLR. If possible, the MLE should > be > +built with KASLR disabled:: Why does Secure Launch not interoperate with KASLR? Re: IOMMUs > +It is recommended that no other command line options should be set to > override > +the defaults above. What happens if they are? Does doing so change the security posture of the system? If so, will the measurements be different in a way that demonstrates the system is in an insecure state? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v6 02/14] 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 --- Documentation/security/index.rst | 1 + Documentation/security/launch-integrity/index.rst | 10 + .../security/launch-integrity/principles.rst | 313 .../launch-integrity/secure_launch_details.rst | 564 + .../launch-integrity/secure_launch_overview.rst| 220 5 files changed, 1108 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 6ed8d2f..fade37e 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -18,3 +18,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 000..28eed91d --- /dev/null +++ b/Documentation/security/launch-integrity/index.rst @@ -0,0 +1,10 @@ += +System Launch Integrity documentation += + +.. toctree:: + + 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 000..73cf063 --- /dev/null +++ b/Documentation/security/launch-integrity/principles.rst @@ -0,0 +1,313 @@ +=== +System Launch Integrity +=== + +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. Through out this document +terminology from the Trusted Computing Group (TCG) and National Institue for +Science and Technology (NIST) is used to ensure a vendor nutrual 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 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 +
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > += > +System Launch Integrity documentation > += > + > +.. toctree:: By convention, doc toctree have 2-level depth (only page title and first-level headings are visible). You may consider adding `:maxdepth: 2` option. > diff --git a/Documentation/security/launch-integrity/principles.rst > b/Documentation/security/launch-integrity/principles.rst > new file mode 100644 > index 000..73cf063 > --- /dev/null > +++ b/Documentation/security/launch-integrity/principles.rst > @@ -0,0 +1,313 @@ > +=== > +System Launch Integrity > +=== > + > +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. Through out this document > +terminology from the Trusted Computing Group (TCG) and National Institue for > +Science and Technology (NIST) is used to ensure a vendor nutrual 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 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 are a subset of these mechanisms, commonly > +referred to as security mechanisms, that are present to help ensure the > system > +produces the expected result or at least detect the potential of an > unexpected > +result may have happened. 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 and > for > +trusted mechanism
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On 5/5/23 12:19, Simon Horman wrote: On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: Introduce background, overview and configuration/ABI information for the Secure Launch kernel feature. Signed-off-by: Daniel P. Smith Signed-off-by: Ross Philipson Hi Ross and Daniel, some minor nits from my side. All good points. We will fix those. Thanks Ross --- Documentation/security/index.rst | 1 + Documentation/security/launch-integrity/index.rst | 10 + .../security/launch-integrity/principles.rst | 313 .../launch-integrity/secure_launch_details.rst | 564 + .../launch-integrity/secure_launch_overview.rst| 220 5 files changed, 1108 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 6ed8d2f..fade37e 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -18,3 +18,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 000..28eed91d --- /dev/null +++ b/Documentation/security/launch-integrity/index.rst @@ -0,0 +1,10 @@ I believe an SPDX tag should go at the top of each .rst file. += +System Launch Integrity documentation += + +.. toctree:: + + 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 000..73cf063 --- /dev/null +++ b/Documentation/security/launch-integrity/principles.rst @@ -0,0 +1,313 @@ +=== +System Launch Integrity +=== + +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. Through out this document +terminology from the Trusted Computing Group (TCG) and National Institue for s/Institue/Institute/ ... +Trust Chains + + +Bulding upon the understanding of security mechanisms to establish load-time s/Bulding/Building/ ... diff --git a/Documentation/security/launch-integrity/secure_launch_details.rst b/Documentation/security/launch-integrity/secure_launch_details.rst ... +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 setup +the environment during post-launch. The details for the SLRT are documented +in the TrenchBoot Secure Launch Specifcation [3]_. s/Specifcation/Specification/ ... ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > Introduce background, overview and configuration/ABI information > for the Secure Launch kernel feature. > > Signed-off-by: Daniel P. Smith > Signed-off-by: Ross Philipson Hi Ross and Daniel, some minor nits from my side. > --- > Documentation/security/index.rst | 1 + > Documentation/security/launch-integrity/index.rst | 10 + > .../security/launch-integrity/principles.rst | 313 > .../launch-integrity/secure_launch_details.rst | 564 > + > .../launch-integrity/secure_launch_overview.rst| 220 > 5 files changed, 1108 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 6ed8d2f..fade37e 100644 > --- a/Documentation/security/index.rst > +++ b/Documentation/security/index.rst > @@ -18,3 +18,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 000..28eed91d > --- /dev/null > +++ b/Documentation/security/launch-integrity/index.rst > @@ -0,0 +1,10 @@ I believe an SPDX tag should go at the top of each .rst file. > += > +System Launch Integrity documentation > += > + > +.. toctree:: > + > + 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 000..73cf063 > --- /dev/null > +++ b/Documentation/security/launch-integrity/principles.rst > @@ -0,0 +1,313 @@ > +=== > +System Launch Integrity > +=== > + > +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. Through out this document > +terminology from the Trusted Computing Group (TCG) and National Institue for s/Institue/Institute/ ... > +Trust Chains > + > + > +Bulding upon the understanding of security mechanisms to establish load-time s/Bulding/Building/ ... > diff --git > a/Documentation/security/launch-integrity/secure_launch_details.rst > b/Documentation/security/launch-integrity/secure_launch_details.rst ... > +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 setup > +the environment during post-launch. The details for the SLRT are documented > +in the TrenchBoot Secure Launch Specifcation [3]_. s/Specifcation/Specification/ ... ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
