* [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
@ 2019-08-05 7:47 Yao, Jiewen
2019-08-05 14:11 ` Vincent Zimmer
2019-08-07 17:46 ` [edk2-devel] " Laszlo Ersek
0 siblings, 2 replies; 6+ messages in thread
From: Yao, Jiewen @ 2019-08-05 7:47 UTC (permalink / raw)
To: devel; +Cc: Vincent Zimmer
This patch adds "Threat model for EDK II" as the appendix section
of "EDK II secure coding guide" document.
The threat model discussed here is a general guide and serves as the baseline of
the EDK II firmware. For each specific feature in EDK II firmware, there might be
additional feature-based threat models in addition to the general threat model.
The full gitbook can be also avaiable at
https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model.
Cc: Vincent Zimmer <vincent.zimmer@intel.com>
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
---
SUMMARY.md | 6 ++
appendix_threat_model_for_edk_ii/README.md | 70 +++++++++++++++++++
.../asset_boot_flow.md | 63 +++++++++++++++++
.../asset_build_tool.md | 39 +++++++++++
.../asset_flash_content.md | 59 ++++++++++++++++
.../asset_management_mode.md | 58 +++++++++++++++
.../asset_s3_resume.md | 61 ++++++++++++++++
7 files changed, 356 insertions(+)
create mode 100644 appendix_threat_model_for_edk_ii/README.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_boot_flow.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_build_tool.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_flash_content.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_management_mode.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_s3_resume.md
diff --git a/SUMMARY.md b/SUMMARY.md
index dc22f1e..d56dee3 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -38,6 +38,12 @@
* [SMM](secure_coding_guidelines_intel_platforms/smm.md)
* [Intel® Boot Guard](secure_coding_guidelines_intel_platforms/intel_boot_guard.md)
* [Intel® Bios Guard](secure_coding_guidelines_intel_platforms/intel_bios_guard.md)
+* [Appendix - Threat Model for EDK II](appendix_threat_model_for_edk_ii/README.md)
+ * [Asset: Flash Content](appendix_threat_model_for_edk_ii/asset_flash_content.md)
+ * [Asset: Boot Flow](appendix_threat_model_for_edk_ii/asset_boot_flow.md)
+ * [Asset: S3 Resume](appendix_threat_model_for_edk_ii/asset_s3_resume.md)
+ * [Asset: Management Mode](appendix_threat_model_for_edk_ii/asset_management_mode.md)
+ * [Asset: Build Tool](appendix_threat_model_for_edk_ii/asset_build_tool.md)
* [References](references.md)
* [Books and Papers ](references.md#books-and-papers)
* [Web ](references.md#web)
diff --git a/appendix_threat_model_for_edk_ii/README.md b/appendix_threat_model_for_edk_ii/README.md
new file mode 100644
index 0000000..6c4ac16
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/README.md
@@ -0,0 +1,70 @@
+<!--- @file
+ README.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+# Appendix:Threat Model for EDK II {#appendix-threat-model-for-edk-ii}
+This chapter provides the basic assumptions for the threat model of EDK II firmware. The threat model discussed here is a general guide and serves as the baseline of the EDK II firmware. For each specific feature in EDK II firmware, there might be additional feature-based threat models in addition to the general threat model.
+
+In [UEFI Threat Model](https://uefi.org/sites/default/files/resources/Intel-UEFI-ThreatModel.pdf), we discussed the asset, threat and mitigation. Here we will revisit these items and based upon [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)).
+
+| Threat | Desired Property |
+| --- | --- |
+| Spoofing | Authentication |
+| Tampering | Integrity |
+| Repudiation | Non-Repudiation |
+| Information Disclosure | Confidentiality |
+| Denial of Service | Availability |
+| Elevation of Privilege | Authorization |
+
+In EDK II firmware, the denial of service can be temporary in the current boot, or permanent in which case the system never boot again. The latter is more serious and it is named as permanent denial of service (PDoS).
+
+We will consider the below adversary for the EDK II firmware:
+
+| Adversary | Capability |
+| --- | --- |
+| Network Attacker | The attacker may connect to the system by network in order to eavesdrop, intercept, masquerade, or modify the network packet. |
+| Unprivileged Software Attacker | The attacker may run ring-3 software in an OS application layer. The attacker may perform a software based side channel attack (such as using cache timing). |
+| System Software Attacker | The attacker may run ring-0 software in the OS kernel or hypervisor, or run 3rd party firmware code in firmware boot phase. The attacker may perform the software based side channel attack (such as using cache timing, performance counters, branch information, or power status). |
+| Simple Hardware Attacker | The attacker may touch the platform hardware (such as power button or jumper) and attach/remove a simple malicious device (such as hardware debugger, PCI Leach to the external port, PCIE card to the PCIE slot, memory DIMM, NIC cable, hard drive, keyboard, USB device, Bluetooth device). The attacker may hijack the simple system bus (such as the SPI bus or I2C bus). |
+| Skilled Hardware Attacker | The attacker may hijack the complex system bus (such as memory bus, or PCI express bus). The attacker may perform the hardware based side channel attack, such as power analysis, thermal analysis, or electromagnetic analysis. The attacker may perform a glitch attack. |
+
+We will consider the below mitigations for the EDKII firmware:
+
+| Mitigation | Objective |
+| --- | --- |
+| Protection | The mitigation is to prevent such an attack for damaging the system. |
+| Detection | The mitigation is to detect if the system is under attack. |
+| Recovery | The mitigation is to recover the system if it is under attack. |
+
+* Asset: Flash Content
+* Asset: Boot Flow
+* Asset: S3 Resume
+* Asset: Management Mode
+* Asset: Build Tool
diff --git a/appendix_threat_model_for_edk_ii/asset_boot_flow.md b/appendix_threat_model_for_edk_ii/asset_boot_flow.md
new file mode 100644
index 0000000..0d132c6
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_boot_flow.md
@@ -0,0 +1,63 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Boot Flow {#asset-boot-flow}
+
+The main system firmware work is to initialize the silicon and then transfer control to an operating system. Because the firmware is almost the first component running on the system, another responsibility of the system firmware is to maintain the secure boot chain (defined in UEFI specification) and the trusted boot chain (defined by TCG).
+
+Here the secure boot chain means that the first entity needs to verify if the second entity is good before running it, not run the second entity if the verification fails. The trusted boot chain means that the first entity needs to measure the second entity before running it and then always run the second entity. The attestation may happen later. The system firmware needs to maintain both boot flows carefully. The verification and measurement must not be bypassed.
+
+In addition, the system firmware may need to authenticate the end user, to determine if the user is authorized to perform some action. For example, the user may be asked to input a hard driver password to continue the boot. Or the user may be asked to input an administrator password to enter a setup page. Those actions must not be bypassed as well.
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | If the firmware needs to authenticate the user, the attacker may spoof the identity, or bypass the authentication check. |
+| Tampering | The attacker may want to modify the secure boot logic or trusted boot logic (either code or configuration data) to bypass the verification or measurement. |
+| Repudiation | N/A |
+| Information Disclosure | The user identity and device password are secret information. The attacker may want to steal them. |
+| Denial of Service | The attacker may modify the secure boot configuration data to cause a system crash during verification. |
+| Elevation of Privilege | If the attacker bypasses the user authentication, he or she may enter firmware setup page to modify the configuration.If the attacker bypasses the secure boot verification, he or she may run the unauthorized 3rd part code in the ring-0 environment. |
+
+
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | The attacker may send malformed network packets to inject code into the system.<BR>The attacker may send a bad UEFI image to bypass or break the secure boot logic. |
+| Unprivileged Software Attacker | The attacker may write a malformed UEFI authenticated variable to break the secure boot configuration. |
+| System Software Attacker | The attacker may send a command to the isolated execution environment in order to modify the secure boot configuration.<BR>The attacker may enable a side channel to get secrets from memory. |
+| Simple Hardware Attacker | The attacker may attach PCI Leach to perform DMA attack to read the secret from memory, or write the code region to bypass the verification. |
+| Skilled Hardware Attacker | The attacker may hijack the memory bus to read secrets from memory, or write the code region to bypass the verification. |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | Do check for untrusted external input before use (such as network packet, option ROM, OS loader, and UEFI authenticated variable). Do not run any untrusted 3rd part code before verification.<BR>If the secret is generated, it must be cleared after use (such as temporary input from HII). If the secret needs to be stored, the choice includes: to save secret to hardware directly (such as OPAL password), to save hash plus salt to a UEFI variable (such as user password), to save the secret in an isolated environment (such as TPM MOR2). Side channel prevention must be applied in this case.<BR>DMA protection must be enabled. Memory encryption must be used if the memory bus attack is in scope. |
+| Detection | N/A |
+| Recovery | N/A |
diff --git a/appendix_threat_model_for_edk_ii/asset_build_tool.md b/appendix_threat_model_for_edk_ii/asset_build_tool.md
new file mode 100644
index 0000000..d258a10
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_build_tool.md
@@ -0,0 +1,39 @@
+<!--- @file
+ asset_build_tool.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Build Tool {#asset-build-tool}
+
+In 1983, Ken Thompson received the Turing Award with Dennis Ritchie. There he delivered a speech - [Reflections on Trusting Trust](https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf), and demonstrated how to inject a Trojan Horse into the compiler. Afterward the compiler generated a buggy binary. It is not impossible.
+
+This is not a traditional attack to the final system, but it represents an attack to the tool chain in the build environment.
+
+The mitigation is: only trust the tool chain from a trusted source with the source code, and protect the tool chain in the build environment.
+
diff --git a/appendix_threat_model_for_edk_ii/asset_flash_content.md b/appendix_threat_model_for_edk_ii/asset_flash_content.md
new file mode 100644
index 0000000..bb7c3c8
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_flash_content.md
@@ -0,0 +1,59 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Flash Content {#asset-flash-content}
+
+NIST [SP 800-147](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-147.pdf) and [SP 800-147B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-147B.pdf) provide system firmware protection guidelines, including the detailed information on system firmware protection and update. NIST [SP 800-193](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf) provides platform firmware resiliency guidelines. It extends protection to 3 principles: protection, detection, and recovery. It also enlarges the scope from system firmware (BIOS) to all the firmware on the platform.
+
+The flash content here includes both firmware code (such as PEI, DXE, SMM etc) and firmware data (such as UEFI variables, Microcode, etc).
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | N/A |
+| Tampering | If the firmware is not protected or locked, the attacker might modify the firmware directly.<BR>If the firmware update process is not authenticated, the attacker might send a malicious firmware update image for update. |
+| Repudiation | N/A |
+| Information Disclosure | If the system software stores the secret in the firmware, the attacker may read the firmware content and get the secret. |
+| Denial of Service | If the attacker can modify the firmware content (code or data) and cause the firmware crash, the system might no longer boot. It becomes a permanent denial of service. |
+| Elevation of Privilege | If the attacker can modify the firmware content (code or data) and store a Trojan in firmware, the Trojan may hide itself and gain the higher privilege. |
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | If the network is enabled before SMM lock and flash lock, the attacker may send mal-formed network packets. |
+| Unprivileged Software Attacker | The attacker may trigger a firmware update, or write the UEFI variable. |
+| System Software Attacker | The attacker may access a silicon register to unlock the flash access register.<BR>The attacker may create a race condition to break the flash write protection or flash update authentication. |
+| Simple Hardware Attacker | The attacker may press the power button during flash update or recovery, or set a jumper to modify the system boot mode from normal boot to recovery or even manufacturing mode.<BR>The attacker may attach PCI Leach to perform DMA attack during flash update or recovery.<BR>The attacker may hijack the SPI bus to read or write to the chip data. |
+| Skilled Hardware Attacker | N/A |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | For the code region, the flash write protection must always be applied. During the flash update, the new firmware image must be authenticated and the version must be checked to prevent a rollback attack. In order to mitigate Time-of-check/Time-of-use (TOC/TOU) attacks, the new image must be copied to a secure environment before the check. The DMA protection must be enabled during flash update.<BR>For the data region, the UEFI authenticated variable write must happen in an isolated execution environment. The authenticated variable data must be authenticated and the rollback protection must be applied. Just as in code region protection, in order to mitigate TOC/TOU attack, new variable content must be copied to a secure environment before the check and DMA protection must be applied to this environment. In addition, the secret must not be saved to the firmware code or data region. |
+| Detection | The detection happens in the next boot.<BR>For the code region, the industry may have different solutions to make sure the initial boot code is unmodified, such as Project Cerberus, Intel® Boot Guard, etc.<BR>For the data region, the UEFI variable driver needs to detect if the variable region is modified without using UEFI variable services. |
+| Recovery | If something wrong is detected, the entity which detects the failure needs to start the recovery process, and the recovery data must be in a known good and secure configuration and be delivered from a trusted and always available source. |
diff --git a/appendix_threat_model_for_edk_ii/asset_management_mode.md b/appendix_threat_model_for_edk_ii/asset_management_mode.md
new file mode 100644
index 0000000..d5028b7
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_management_mode.md
@@ -0,0 +1,58 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Management Mode {#asset-management-mode}
+
+Management mode is a special system execution environment. X86 systems have system management mode (SMM), and ARM has ARM TrustZone. The firmware code in management mode is considered as a secure world and having high privilege.
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | N/A |
+| Tampering | The attacker may update the management mode memory to inject code or data. |
+| Repudiation | N/A |
+| Information Disclosure | The management mode may contain a secret (such as password, TPM MOR2 entropy), or its own information (code and data structure location). This information may be exposed to normal world. |
+| Denial of Service | The management mode only has limited resource (such as memory). The attacker may send command to management mode code to make it run out of resource. |
+| Elevation of Privilege | The attacker may gain unauthorized execution rights in management mode. For example, if the management code calls the normal world code, the attacker may replace the original code with malicious code to gain the privilege.<BR>The attacker may construct a confused-deputy attack for management mode. For example, the OS kernel may send a command to management mode to let it modify the hypervisor memory or management mode memory. |
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | N/A |
+| Unprivileged Software Attacker | N/A |
+| System Software Attacker | The attacker may take advantage of an implementation flaw in the management mode code to read or modify the management mode content, or content of a higher privilege environment, such as a hypervisor.<BR>The attacker may use a side channel to steal a secret in the management mode memory. |
+| Simple Hardware Attacker | N/A |
+| Skilled Hardware Attacker | N/A |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | The management mode code must lock the management mode after it is constructed, no later than 3rd part code running.<BR>The management mode code must not call out to the normal world code.<BR>The system must remove unnecessary management mode handlers.<BR>The required management mode handler must check the untrusted external input, including the communication buffer, the pointer inside of the communication buffer, the general purpose register served as communication buffer pointer, the hardware base address register. The checked content must be copied into management mode memory to prevent TOC/TOU.<BR>The management mode handler must prevent unauthorized access to itself and high privileged content such as hypervisor or OS kernel memory.<BR>The management mode handler must prevent side channel attacks for the secret.<BR>The management mode handler must not allocate more resources to serve the request. If additional sources are allocated, they must be freed before the handler return to the normal world. |
+| Detection | N/A |
+| Recovery | N/A |
+
diff --git a/appendix_threat_model_for_edk_ii/asset_s3_resume.md b/appendix_threat_model_for_edk_ii/asset_s3_resume.md
new file mode 100644
index 0000000..c514460
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_s3_resume.md
@@ -0,0 +1,61 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: S3 Resume {#asset-s3-resume}
+
+S3 resume is a special boot flow. It is defined by ACPI specification. During S3 resume, the system restores the configuration from a normal boot and jumps to OS waking vector.
+
+All protection applied to the normal boot must also be applied in S3 resume.
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | N/A |
+| Tampering | The attacker may try to modify the S3 configuration, also known as S3 boot script. |
+| Repudiation | N/A |
+| Information Disclosure | If the s3 configuration includes a secret (such as HDD password), the attacker may want to steal the secret. |
+| Denial of Service | The attacker may destroy the S3 configuration to prevent the system from booting. |
+| Elevation of Privilege | The attacker may disable the protections stored in the S3 configuration such as register lock. |
+
+
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | N/A |
+| Unprivileged Software Attacker | The attacker may write a malformed UEFI variable to break the S3 configuration. |
+| System Software Attacker | The attacker may send a command to the isolated execution environment to modify the S3 configuration. If there is a secret saved in the isolated environment, the attacker may send a commend to get the secret, or use a side channel to steal the secret. |
+| Simple Hardware Attacker | N/A |
+| Skilled Hardware Attacker | N/A |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | The S3 configuration data must be saved to a secure place. For example, embedded into read only code region, a read only variable, an isolated execution environment, or a lock box.<BR>If the S3 configuration data is secret, then it must be saved in an isolated execution environment or a lock box to prevent unauthorized reads. |
+| Detection | N/A |
+| Recovery | N/A |
--
2.19.2.windows.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
2019-08-05 7:47 [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II Yao, Jiewen
@ 2019-08-05 14:11 ` Vincent Zimmer
2019-08-07 17:46 ` [edk2-devel] " Laszlo Ersek
1 sibling, 0 replies; 6+ messages in thread
From: Vincent Zimmer @ 2019-08-05 14:11 UTC (permalink / raw)
To: Yao, Jiewen, devel@edk2.groups.io, Felix Polyudov,
infosec@edk2.groups.io
This looks good.
Helps address some of the concerns brought up in evaluating secure coding guidelines for alternate feature implementations, too.
Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
-----Original Message-----
From: Yao, Jiewen
Sent: Monday, August 5, 2019 12:48 AM
To: devel@edk2.groups.io
Cc: Zimmer, Vincent <vincent.zimmer@intel.com>
Subject: [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
This patch adds "Threat model for EDK II" as the appendix section
of "EDK II secure coding guide" document.
The threat model discussed here is a general guide and serves as the baseline of
the EDK II firmware. For each specific feature in EDK II firmware, there might be
additional feature-based threat models in addition to the general threat model.
The full gitbook can be also avaiable at
https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model.
Cc: Vincent Zimmer <vincent.zimmer@intel.com>
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
---
SUMMARY.md | 6 ++
appendix_threat_model_for_edk_ii/README.md | 70 +++++++++++++++++++
.../asset_boot_flow.md | 63 +++++++++++++++++
.../asset_build_tool.md | 39 +++++++++++
.../asset_flash_content.md | 59 ++++++++++++++++
.../asset_management_mode.md | 58 +++++++++++++++
.../asset_s3_resume.md | 61 ++++++++++++++++
7 files changed, 356 insertions(+)
create mode 100644 appendix_threat_model_for_edk_ii/README.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_boot_flow.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_build_tool.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_flash_content.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_management_mode.md
create mode 100644 appendix_threat_model_for_edk_ii/asset_s3_resume.md
diff --git a/SUMMARY.md b/SUMMARY.md
index dc22f1e..d56dee3 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -38,6 +38,12 @@
* [SMM](secure_coding_guidelines_intel_platforms/smm.md)
* [Intel® Boot Guard](secure_coding_guidelines_intel_platforms/intel_boot_guard.md)
* [Intel® Bios Guard](secure_coding_guidelines_intel_platforms/intel_bios_guard.md)
+* [Appendix - Threat Model for EDK II](appendix_threat_model_for_edk_ii/README.md)
+ * [Asset: Flash Content](appendix_threat_model_for_edk_ii/asset_flash_content.md)
+ * [Asset: Boot Flow](appendix_threat_model_for_edk_ii/asset_boot_flow.md)
+ * [Asset: S3 Resume](appendix_threat_model_for_edk_ii/asset_s3_resume.md)
+ * [Asset: Management Mode](appendix_threat_model_for_edk_ii/asset_management_mode.md)
+ * [Asset: Build Tool](appendix_threat_model_for_edk_ii/asset_build_tool.md)
* [References](references.md)
* [Books and Papers ](references.md#books-and-papers)
* [Web ](references.md#web)
diff --git a/appendix_threat_model_for_edk_ii/README.md b/appendix_threat_model_for_edk_ii/README.md
new file mode 100644
index 0000000..6c4ac16
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/README.md
@@ -0,0 +1,70 @@
+<!--- @file
+ README.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+# Appendix:Threat Model for EDK II {#appendix-threat-model-for-edk-ii}
+This chapter provides the basic assumptions for the threat model of EDK II firmware. The threat model discussed here is a general guide and serves as the baseline of the EDK II firmware. For each specific feature in EDK II firmware, there might be additional feature-based threat models in addition to the general threat model.
+
+In [UEFI Threat Model](https://uefi.org/sites/default/files/resources/Intel-UEFI-ThreatModel.pdf), we discussed the asset, threat and mitigation. Here we will revisit these items and based upon [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security)).
+
+| Threat | Desired Property |
+| --- | --- |
+| Spoofing | Authentication |
+| Tampering | Integrity |
+| Repudiation | Non-Repudiation |
+| Information Disclosure | Confidentiality |
+| Denial of Service | Availability |
+| Elevation of Privilege | Authorization |
+
+In EDK II firmware, the denial of service can be temporary in the current boot, or permanent in which case the system never boot again. The latter is more serious and it is named as permanent denial of service (PDoS).
+
+We will consider the below adversary for the EDK II firmware:
+
+| Adversary | Capability |
+| --- | --- |
+| Network Attacker | The attacker may connect to the system by network in order to eavesdrop, intercept, masquerade, or modify the network packet. |
+| Unprivileged Software Attacker | The attacker may run ring-3 software in an OS application layer. The attacker may perform a software based side channel attack (such as using cache timing). |
+| System Software Attacker | The attacker may run ring-0 software in the OS kernel or hypervisor, or run 3rd party firmware code in firmware boot phase. The attacker may perform the software based side channel attack (such as using cache timing, performance counters, branch information, or power status). |
+| Simple Hardware Attacker | The attacker may touch the platform hardware (such as power button or jumper) and attach/remove a simple malicious device (such as hardware debugger, PCI Leach to the external port, PCIE card to the PCIE slot, memory DIMM, NIC cable, hard drive, keyboard, USB device, Bluetooth device). The attacker may hijack the simple system bus (such as the SPI bus or I2C bus). |
+| Skilled Hardware Attacker | The attacker may hijack the complex system bus (such as memory bus, or PCI express bus). The attacker may perform the hardware based side channel attack, such as power analysis, thermal analysis, or electromagnetic analysis. The attacker may perform a glitch attack. |
+
+We will consider the below mitigations for the EDKII firmware:
+
+| Mitigation | Objective |
+| --- | --- |
+| Protection | The mitigation is to prevent such an attack for damaging the system. |
+| Detection | The mitigation is to detect if the system is under attack. |
+| Recovery | The mitigation is to recover the system if it is under attack. |
+
+* Asset: Flash Content
+* Asset: Boot Flow
+* Asset: S3 Resume
+* Asset: Management Mode
+* Asset: Build Tool
diff --git a/appendix_threat_model_for_edk_ii/asset_boot_flow.md b/appendix_threat_model_for_edk_ii/asset_boot_flow.md
new file mode 100644
index 0000000..0d132c6
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_boot_flow.md
@@ -0,0 +1,63 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Boot Flow {#asset-boot-flow}
+
+The main system firmware work is to initialize the silicon and then transfer control to an operating system. Because the firmware is almost the first component running on the system, another responsibility of the system firmware is to maintain the secure boot chain (defined in UEFI specification) and the trusted boot chain (defined by TCG).
+
+Here the secure boot chain means that the first entity needs to verify if the second entity is good before running it, not run the second entity if the verification fails. The trusted boot chain means that the first entity needs to measure the second entity before running it and then always run the second entity. The attestation may happen later. The system firmware needs to maintain both boot flows carefully. The verification and measurement must not be bypassed.
+
+In addition, the system firmware may need to authenticate the end user, to determine if the user is authorized to perform some action. For example, the user may be asked to input a hard driver password to continue the boot. Or the user may be asked to input an administrator password to enter a setup page. Those actions must not be bypassed as well.
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | If the firmware needs to authenticate the user, the attacker may spoof the identity, or bypass the authentication check. |
+| Tampering | The attacker may want to modify the secure boot logic or trusted boot logic (either code or configuration data) to bypass the verification or measurement. |
+| Repudiation | N/A |
+| Information Disclosure | The user identity and device password are secret information. The attacker may want to steal them. |
+| Denial of Service | The attacker may modify the secure boot configuration data to cause a system crash during verification. |
+| Elevation of Privilege | If the attacker bypasses the user authentication, he or she may enter firmware setup page to modify the configuration.If the attacker bypasses the secure boot verification, he or she may run the unauthorized 3rd part code in the ring-0 environment. |
+
+
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | The attacker may send malformed network packets to inject code into the system.<BR>The attacker may send a bad UEFI image to bypass or break the secure boot logic. |
+| Unprivileged Software Attacker | The attacker may write a malformed UEFI authenticated variable to break the secure boot configuration. |
+| System Software Attacker | The attacker may send a command to the isolated execution environment in order to modify the secure boot configuration.<BR>The attacker may enable a side channel to get secrets from memory. |
+| Simple Hardware Attacker | The attacker may attach PCI Leach to perform DMA attack to read the secret from memory, or write the code region to bypass the verification. |
+| Skilled Hardware Attacker | The attacker may hijack the memory bus to read secrets from memory, or write the code region to bypass the verification. |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | Do check for untrusted external input before use (such as network packet, option ROM, OS loader, and UEFI authenticated variable). Do not run any untrusted 3rd part code before verification.<BR>If the secret is generated, it must be cleared after use (such as temporary input from HII). If the secret needs to be stored, the choice includes: to save secret to hardware directly (such as OPAL password), to save hash plus salt to a UEFI variable (such as user password), to save the secret in an isolated environment (such as TPM MOR2). Side channel prevention must be applied in this case.<BR>DMA protection must be enabled. Memory encryption must be used if the memory bus attack is in scope. |
+| Detection | N/A |
+| Recovery | N/A |
diff --git a/appendix_threat_model_for_edk_ii/asset_build_tool.md b/appendix_threat_model_for_edk_ii/asset_build_tool.md
new file mode 100644
index 0000000..d258a10
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_build_tool.md
@@ -0,0 +1,39 @@
+<!--- @file
+ asset_build_tool.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Build Tool {#asset-build-tool}
+
+In 1983, Ken Thompson received the Turing Award with Dennis Ritchie. There he delivered a speech - [Reflections on Trusting Trust](https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf), and demonstrated how to inject a Trojan Horse into the compiler. Afterward the compiler generated a buggy binary. It is not impossible.
+
+This is not a traditional attack to the final system, but it represents an attack to the tool chain in the build environment.
+
+The mitigation is: only trust the tool chain from a trusted source with the source code, and protect the tool chain in the build environment.
+
diff --git a/appendix_threat_model_for_edk_ii/asset_flash_content.md b/appendix_threat_model_for_edk_ii/asset_flash_content.md
new file mode 100644
index 0000000..bb7c3c8
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_flash_content.md
@@ -0,0 +1,59 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Flash Content {#asset-flash-content}
+
+NIST [SP 800-147](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-147.pdf) and [SP 800-147B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-147B.pdf) provide system firmware protection guidelines, including the detailed information on system firmware protection and update. NIST [SP 800-193](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf) provides platform firmware resiliency guidelines. It extends protection to 3 principles: protection, detection, and recovery. It also enlarges the scope from system firmware (BIOS) to all the firmware on the platform.
+
+The flash content here includes both firmware code (such as PEI, DXE, SMM etc) and firmware data (such as UEFI variables, Microcode, etc).
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | N/A |
+| Tampering | If the firmware is not protected or locked, the attacker might modify the firmware directly.<BR>If the firmware update process is not authenticated, the attacker might send a malicious firmware update image for update. |
+| Repudiation | N/A |
+| Information Disclosure | If the system software stores the secret in the firmware, the attacker may read the firmware content and get the secret. |
+| Denial of Service | If the attacker can modify the firmware content (code or data) and cause the firmware crash, the system might no longer boot. It becomes a permanent denial of service. |
+| Elevation of Privilege | If the attacker can modify the firmware content (code or data) and store a Trojan in firmware, the Trojan may hide itself and gain the higher privilege. |
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | If the network is enabled before SMM lock and flash lock, the attacker may send mal-formed network packets. |
+| Unprivileged Software Attacker | The attacker may trigger a firmware update, or write the UEFI variable. |
+| System Software Attacker | The attacker may access a silicon register to unlock the flash access register.<BR>The attacker may create a race condition to break the flash write protection or flash update authentication. |
+| Simple Hardware Attacker | The attacker may press the power button during flash update or recovery, or set a jumper to modify the system boot mode from normal boot to recovery or even manufacturing mode.<BR>The attacker may attach PCI Leach to perform DMA attack during flash update or recovery.<BR>The attacker may hijack the SPI bus to read or write to the chip data. |
+| Skilled Hardware Attacker | N/A |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | For the code region, the flash write protection must always be applied. During the flash update, the new firmware image must be authenticated and the version must be checked to prevent a rollback attack. In order to mitigate Time-of-check/Time-of-use (TOC/TOU) attacks, the new image must be copied to a secure environment before the check. The DMA protection must be enabled during flash update.<BR>For the data region, the UEFI authenticated variable write must happen in an isolated execution environment. The authenticated variable data must be authenticated and the rollback protection must be applied. Just as in code region protection, in order to mitigate TOC/TOU attack, new variable content must be copied to a secure environment before the check and DMA protection must be applied to this environment. In addition, the secret must not be saved to the firmware code or data region. |
+| Detection | The detection happens in the next boot.<BR>For the code region, the industry may have different solutions to make sure the initial boot code is unmodified, such as Project Cerberus, Intel® Boot Guard, etc.<BR>For the data region, the UEFI variable driver needs to detect if the variable region is modified without using UEFI variable services. |
+| Recovery | If something wrong is detected, the entity which detects the failure needs to start the recovery process, and the recovery data must be in a known good and secure configuration and be delivered from a trusted and always available source. |
diff --git a/appendix_threat_model_for_edk_ii/asset_management_mode.md b/appendix_threat_model_for_edk_ii/asset_management_mode.md
new file mode 100644
index 0000000..d5028b7
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_management_mode.md
@@ -0,0 +1,58 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: Management Mode {#asset-management-mode}
+
+Management mode is a special system execution environment. X86 systems have system management mode (SMM), and ARM has ARM TrustZone. The firmware code in management mode is considered as a secure world and having high privilege.
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | N/A |
+| Tampering | The attacker may update the management mode memory to inject code or data. |
+| Repudiation | N/A |
+| Information Disclosure | The management mode may contain a secret (such as password, TPM MOR2 entropy), or its own information (code and data structure location). This information may be exposed to normal world. |
+| Denial of Service | The management mode only has limited resource (such as memory). The attacker may send command to management mode code to make it run out of resource. |
+| Elevation of Privilege | The attacker may gain unauthorized execution rights in management mode. For example, if the management code calls the normal world code, the attacker may replace the original code with malicious code to gain the privilege.<BR>The attacker may construct a confused-deputy attack for management mode. For example, the OS kernel may send a command to management mode to let it modify the hypervisor memory or management mode memory. |
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | N/A |
+| Unprivileged Software Attacker | N/A |
+| System Software Attacker | The attacker may take advantage of an implementation flaw in the management mode code to read or modify the management mode content, or content of a higher privilege environment, such as a hypervisor.<BR>The attacker may use a side channel to steal a secret in the management mode memory. |
+| Simple Hardware Attacker | N/A |
+| Skilled Hardware Attacker | N/A |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | The management mode code must lock the management mode after it is constructed, no later than 3rd part code running.<BR>The management mode code must not call out to the normal world code.<BR>The system must remove unnecessary management mode handlers.<BR>The required management mode handler must check the untrusted external input, including the communication buffer, the pointer inside of the communication buffer, the general purpose register served as communication buffer pointer, the hardware base address register. The checked content must be copied into management mode memory to prevent TOC/TOU.<BR>The management mode handler must prevent unauthorized access to itself and high privileged content such as hypervisor or OS kernel memory.<BR>The management mode handler must prevent side channel attacks for the secret.<BR>The management mode handler must not allocate more resources to serve the request. If additional sources are allocated, they must be freed before the handler return to the normal world. |
+| Detection | N/A |
+| Recovery | N/A |
+
diff --git a/appendix_threat_model_for_edk_ii/asset_s3_resume.md b/appendix_threat_model_for_edk_ii/asset_s3_resume.md
new file mode 100644
index 0000000..c514460
--- /dev/null
+++ b/appendix_threat_model_for_edk_ii/asset_s3_resume.md
@@ -0,0 +1,61 @@
+<!--- @file
+ asset_flash_content.md for appendix_threat_model_for_edk_ii for EDK II Secure Coding Guide
+
+ Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## Asset: S3 Resume {#asset-s3-resume}
+
+S3 resume is a special boot flow. It is defined by ACPI specification. During S3 resume, the system restores the configuration from a normal boot and jumps to OS waking vector.
+
+All protection applied to the normal boot must also be applied in S3 resume.
+
+| Threat | Example |
+| --- | --- |
+| Spoofing | N/A |
+| Tampering | The attacker may try to modify the S3 configuration, also known as S3 boot script. |
+| Repudiation | N/A |
+| Information Disclosure | If the s3 configuration includes a secret (such as HDD password), the attacker may want to steal the secret. |
+| Denial of Service | The attacker may destroy the S3 configuration to prevent the system from booting. |
+| Elevation of Privilege | The attacker may disable the protections stored in the S3 configuration such as register lock. |
+
+
+
+| Adversary | Example |
+| --- | --- |
+| Network Attacker | N/A |
+| Unprivileged Software Attacker | The attacker may write a malformed UEFI variable to break the S3 configuration. |
+| System Software Attacker | The attacker may send a command to the isolated execution environment to modify the S3 configuration. If there is a secret saved in the isolated environment, the attacker may send a commend to get the secret, or use a side channel to steal the secret. |
+| Simple Hardware Attacker | N/A |
+| Skilled Hardware Attacker | N/A |
+
+| Mitigation | Example |
+| --- | --- |
+| Protection | The S3 configuration data must be saved to a secure place. For example, embedded into read only code region, a read only variable, an isolated execution environment, or a lock box.<BR>If the S3 configuration data is secret, then it must be saved in an isolated execution environment or a lock box to prevent unauthorized reads. |
+| Detection | N/A |
+| Recovery | N/A |
--
2.19.2.windows.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
2019-08-05 7:47 [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II Yao, Jiewen
2019-08-05 14:11 ` Vincent Zimmer
@ 2019-08-07 17:46 ` Laszlo Ersek
2019-08-07 17:59 ` Vincent Zimmer
1 sibling, 1 reply; 6+ messages in thread
From: Laszlo Ersek @ 2019-08-07 17:46 UTC (permalink / raw)
To: jiewen.yao; +Cc: devel, Vincent Zimmer, Laurie Jarlstrom
(+ Laurie)
On 08/05/19 09:47, Yao, Jiewen wrote:
> This patch adds "Threat model for EDK II" as the appendix section
>
> of "EDK II secure coding guide" document.
>
>
> The threat model discussed here is a general guide and serves as the baseline of
>
> the EDK II firmware. For each specific feature in EDK II firmware, there might be
>
> additional feature-based threat models in addition to the general threat model.
>
>
> The full gitbook can be also avaiable at
>
> https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model.
>
>
> Cc: Vincent Zimmer <vincent.zimmer@intel.com>
> Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
>
> Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
>
>
> ---
> SUMMARY.md | 6 ++
> appendix_threat_model_for_edk_ii/README.md | 70 +++++++++++++++++++
> .../asset_boot_flow.md | 63 +++++++++++++++++
> .../asset_build_tool.md | 39 +++++++++++
> .../asset_flash_content.md | 59 ++++++++++++++++
> .../asset_management_mode.md | 58 +++++++++++++++
> .../asset_s3_resume.md | 61 ++++++++++++++++
> 7 files changed, 356 insertions(+)
> create mode 100644 appendix_threat_model_for_edk_ii/README.md
> create mode 100644 appendix_threat_model_for_edk_ii/asset_boot_flow.md
> create mode 100644 appendix_threat_model_for_edk_ii/asset_build_tool.md
> create mode 100644 appendix_threat_model_for_edk_ii/asset_flash_content.md
> create mode 100644 appendix_threat_model_for_edk_ii/asset_management_mode.md
> create mode 100644 appendix_threat_model_for_edk_ii/asset_s3_resume.md
It looks like we have at least two kinds of documents under
<https://github.com/tianocore-docs/>, namely:
- specs (for edk2)
- guides
I know of the article at
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications>,
which presents the specs very nicely.
Do we have a similar wiki article about the guides too?
(If I use the article search box to the right, and enter "guide",
nothing relevant comes up.)
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
2019-08-07 17:46 ` [edk2-devel] " Laszlo Ersek
@ 2019-08-07 17:59 ` Vincent Zimmer
2019-08-07 21:29 ` Yao, Jiewen
2019-08-08 18:51 ` Laszlo Ersek
0 siblings, 2 replies; 6+ messages in thread
From: Vincent Zimmer @ 2019-08-07 17:59 UTC (permalink / raw)
To: devel@edk2.groups.io, lersek@redhat.com, Yao, Jiewen; +Cc: Jarlstrom, Laurie
Laurie created https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers for the security collateral.
Vincent
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Wednesday, August 7, 2019 10:46 AM
To: Yao, Jiewen <jiewen.yao@intel.com>
Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>; Jarlstrom, Laurie <laurie.jarlstrom@intel.com>
Subject: Re: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
(+ Laurie)
On 08/05/19 09:47, Yao, Jiewen wrote:
> This patch adds "Threat model for EDK II" as the appendix section
>
> of "EDK II secure coding guide" document.
>
>
> The threat model discussed here is a general guide and serves as the
> baseline of
>
> the EDK II firmware. For each specific feature in EDK II firmware,
> there might be
>
> additional feature-based threat models in addition to the general threat model.
>
>
> The full gitbook can be also avaiable at
>
> https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model.
>
>
> Cc: Vincent Zimmer <vincent.zimmer@intel.com>
> Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
>
> Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
>
>
> ---
> SUMMARY.md | 6 ++
> appendix_threat_model_for_edk_ii/README.md | 70 +++++++++++++++++++
> .../asset_boot_flow.md | 63 +++++++++++++++++
> .../asset_build_tool.md | 39 +++++++++++
> .../asset_flash_content.md | 59 ++++++++++++++++
> .../asset_management_mode.md | 58 +++++++++++++++
> .../asset_s3_resume.md | 61 ++++++++++++++++
> 7 files changed, 356 insertions(+)
> create mode 100644 appendix_threat_model_for_edk_ii/README.md
> create mode 100644
> appendix_threat_model_for_edk_ii/asset_boot_flow.md
> create mode 100644
> appendix_threat_model_for_edk_ii/asset_build_tool.md
> create mode 100644
> appendix_threat_model_for_edk_ii/asset_flash_content.md
> create mode 100644
> appendix_threat_model_for_edk_ii/asset_management_mode.md
> create mode 100644
> appendix_threat_model_for_edk_ii/asset_s3_resume.md
It looks like we have at least two kinds of documents under <https://github.com/tianocore-docs/>, namely:
- specs (for edk2)
- guides
I know of the article at
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications>,
which presents the specs very nicely.
Do we have a similar wiki article about the guides too?
(If I use the article search box to the right, and enter "guide", nothing relevant comes up.)
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
2019-08-07 17:59 ` Vincent Zimmer
@ 2019-08-07 21:29 ` Yao, Jiewen
2019-08-08 18:51 ` Laszlo Ersek
1 sibling, 0 replies; 6+ messages in thread
From: Yao, Jiewen @ 2019-08-07 21:29 UTC (permalink / raw)
To: Zimmer, Vincent, devel@edk2.groups.io, lersek@redhat.com
Cc: Jarlstrom, Laurie
Right. You can get it from below step:
1) goto https://www.tianocore.org/
2) click "document" on the left, then goto https://www.tianocore.org/docs/
3) click "EDK II Documents wiki page", then goto https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Documents
4) click "EDK II Security White Papers", then goto https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
Or you can search "security" keyword in the wiki search box. Then "EDK II Security White Papers" will show up.
Thank you
Yao Jiewen
> -----Original Message-----
> From: Zimmer, Vincent
> Sent: Thursday, August 8, 2019 1:59 AM
> To: devel@edk2.groups.io; lersek@redhat.com; Yao, Jiewen
> <jiewen.yao@intel.com>
> Cc: Jarlstrom, Laurie <laurie.jarlstrom@intel.com>
> Subject: RE: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide
> PATCH] Add Appendix: Threat Mode for EDK II.
>
> Laurie created
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-Whit
> e-Papers for the security collateral.
>
> Vincent
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
> Ersek
> Sent: Wednesday, August 7, 2019 10:46 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: devel@edk2.groups.io; Zimmer, Vincent <vincent.zimmer@intel.com>;
> Jarlstrom, Laurie <laurie.jarlstrom@intel.com>
> Subject: Re: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide
> PATCH] Add Appendix: Threat Mode for EDK II.
>
> (+ Laurie)
>
> On 08/05/19 09:47, Yao, Jiewen wrote:
> > This patch adds "Threat model for EDK II" as the appendix section
> >
> > of "EDK II secure coding guide" document.
> >
> >
> > The threat model discussed here is a general guide and serves as the
> > baseline of
> >
> > the EDK II firmware. For each specific feature in EDK II firmware,
> > there might be
> >
> > additional feature-based threat models in addition to the general threat
> model.
> >
> >
> > The full gitbook can be also avaiable at
> >
> >
> https://github.com/jyao1/EDK_II_Secure_Coding_Guide/tree/Threat_model
> .
> >
> >
> > Cc: Vincent Zimmer <vincent.zimmer@intel.com>
> > Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
> >
> > Reviewed-by: Vincent Zimmer <vincent.zimmer@intel.com>
> >
> >
> > ---
> > SUMMARY.md | 6 ++
> > appendix_threat_model_for_edk_ii/README.md | 70
> +++++++++++++++++++
> > .../asset_boot_flow.md | 63
> +++++++++++++++++
> > .../asset_build_tool.md | 39 +++++++++++
> > .../asset_flash_content.md | 59
> ++++++++++++++++
> > .../asset_management_mode.md | 58
> +++++++++++++++
> > .../asset_s3_resume.md | 61
> ++++++++++++++++
> > 7 files changed, 356 insertions(+)
> > create mode 100644 appendix_threat_model_for_edk_ii/README.md
> > create mode 100644
> > appendix_threat_model_for_edk_ii/asset_boot_flow.md
> > create mode 100644
> > appendix_threat_model_for_edk_ii/asset_build_tool.md
> > create mode 100644
> > appendix_threat_model_for_edk_ii/asset_flash_content.md
> > create mode 100644
> > appendix_threat_model_for_edk_ii/asset_management_mode.md
> > create mode 100644
> > appendix_threat_model_for_edk_ii/asset_s3_resume.md
>
> It looks like we have at least two kinds of documents under
> <https://github.com/tianocore-docs/>, namely:
> - specs (for edk2)
> - guides
>
> I know of the article at
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specificatio
> ns>,
> which presents the specs very nicely.
>
> Do we have a similar wiki article about the guides too?
>
> (If I use the article search box to the right, and enter "guide", nothing
> relevant comes up.)
>
> Thanks!
> Laszlo
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [edk2-devel] [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II.
2019-08-07 17:59 ` Vincent Zimmer
2019-08-07 21:29 ` Yao, Jiewen
@ 2019-08-08 18:51 ` Laszlo Ersek
1 sibling, 0 replies; 6+ messages in thread
From: Laszlo Ersek @ 2019-08-08 18:51 UTC (permalink / raw)
To: Zimmer, Vincent, devel@edk2.groups.io, Yao, Jiewen; +Cc: Jarlstrom, Laurie
On 08/07/19 19:59, Zimmer, Vincent wrote:
> Laurie created https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers for the security collateral.
Awesome, thanks!
Laszlo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-08-08 18:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-05 7:47 [tianocore-docs EDK_II_Secure_Coding_Guide PATCH] Add Appendix: Threat Mode for EDK II Yao, Jiewen
2019-08-05 14:11 ` Vincent Zimmer
2019-08-07 17:46 ` [edk2-devel] " Laszlo Ersek
2019-08-07 17:59 ` Vincent Zimmer
2019-08-07 21:29 ` Yao, Jiewen
2019-08-08 18:51 ` Laszlo Ersek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox