From 9274db6ed05a900e3f244cdf69ac4a6a514a5e3a Mon Sep 17 00:00:00 2001 From: Ken Lautner Date: Thu, 19 Oct 2023 14:11:46 -0700 Subject: [PATCH] Fixed Markdown errors MdeModulePkg --- .../Library/TraceHubDebugSysTLib/Readme.md | 20 ++++-- .../Library/VariablePolicyLib/ReadMe.md | 70 ++++++++++--------- 2 files changed, 50 insertions(+), 40 deletions(-) diff --git a/MdeModulePkg/Library/TraceHubDebugSysTLib/Readme.md b/MdeModulePkg/Library/TraceHubDebugSysTLib/Readme.md index 9e798a41bf..735e37e1fb 100644 --- a/MdeModulePkg/Library/TraceHubDebugSysTLib/Readme.md +++ b/MdeModulePkg/Library/TraceHubDebugSysTLib/Readme.md @@ -1,26 +1,32 @@ -## Introduction of TrcaceHubDebugSysTLib ## -TrcaceHubDebugSysTLib library is a top level library for dumping Trace Hub messages. +# Introduction of TrcaceHubDebugSysTLib # + +TraceHubDebugSysTLib library is a top level library for dumping Trace Hub messages. It provides Trace Hub related APIs to dump Trace Hub message via MIPI SYS-T submodule. User need to properly configure following Trace Hub related PCDs and HOB. (See MdeModulePkg.dec to get detailed definition for PCDs below) - - PcdTraceHubDebugLevel - - PcdEnableTraceHubDebugMsg - - PcdTraceHubDebugMmioAddress - (See TraceHubDebugInfoHob.h to get detailed definition for HOB below) - - gTraceHubDebugInfoHobGuid + +- PcdTraceHubDebugLevel +- PcdEnableTraceHubDebugMsg +- PcdTraceHubDebugMmioAddress +(See TraceHubDebugInfoHob.h to get detailed definition for HOB below) +- gTraceHubDebugInfoHobGuid ## BaseTraceHubDebugSysTLib.inf ## + System prints Trace Hub message in SEC/PEI/DXE/SMM based on fixed PCDs. Only support single Trace Hub debug instance. ## PeiTraceHubDebugSysTLib.inf ## + System prints Trace Hub message in PEI based on fixed PCDs and HOB. System applies Trace Hub HOB once it detect gTraceHubDebugInfoHobGuid HOB. Trace Hub PCDs will be applied if no HOB exist. ## DxeSmmTraceHubDebugSysTLib.inf ## + System prints Trace Hub message in DXE/SMM based on fixed PCDs and HOB. Trace Hub PCDs will be applied if no HOB exist. ## Note ## + Trace Hub debug library not support DXE_RUNTIME_DRIVER type of module currently. diff --git a/MdeModulePkg/Library/VariablePolicyLib/ReadMe.md b/MdeModulePkg/Library/VariablePolicyLib/ReadMe.md index c2f9850a12..accc701d42 100644 --- a/MdeModulePkg/Library/VariablePolicyLib/ReadMe.md +++ b/MdeModulePkg/Library/VariablePolicyLib/ReadMe.md @@ -4,8 +4,6 @@ version: 1.0 copyright: Copyright (c) Microsoft Corporation. --- -# UEFI Variable Policy - ## Summary UEFI Variable Policy spec aims to describe the DXE protocol interface @@ -17,14 +15,14 @@ The Variable Policy is comprised of a set of policy entries which describe, per UEFI variable (identified by namespace GUID and variable name) the following rules: -- Required variable attributes -- Prohibited variable attributes -- Minimum variable size -- Maximum variable size -- Locking: - - Locking "immediately" - - Locking on creation - - Locking based on a state of another variable +- Required variable attributes +- Prohibited variable attributes +- Minimum variable size +- Maximum variable size +- Locking: + - Locking "immediately" + - Locking on creation + - Locking based on a state of another variable The spec assumes that the Variable Policy Engine runs in a trusted enclave, potentially off the main CPU that runs UEFI. For that reason, @@ -34,9 +32,9 @@ enclave is proprietary. At power-on, the Variable Policy Engine is: -- Enabled -- present policy entries are evaluated on variable access +- Enabled -- present policy entries are evaluated on variable access calls. -- Unlocked -- new policy entries can be registered. +- Unlocked -- new policy entries can be registered. Policy is expected to be clear on power-on. Policy is volatile and not preserved across system reset. @@ -85,7 +83,7 @@ more than once, it will return `EFI_ALREADY_STARTED`. Note, this process is irreversible until the next system reset -- there is no "EnablePolicy" protocol function. -_IMPORTANT NOTE:_ It is strongly recommended that VariablePolicy *NEVER* +_IMPORTANT NOTE:_ It is strongly recommended that VariablePolicy _NEVER_ be disabled in "normal, production boot conditions". It is expected to always be enforced. The most likely reasons to disable are for Manufacturing and Refurbishing scenarios. If in doubt, leave the `gEfiMdeModulePkgTokenSpaceGuid.PcdAllowVariablePolicyEnforcementDisable` @@ -214,18 +212,18 @@ are self-explanatory. `LockPolicyType` can have the following values: -- `VARIABLE_POLICY_TYPE_NO_LOCK` -- means that no variable locking is performed. However, +- `VARIABLE_POLICY_TYPE_NO_LOCK` -- means that no variable locking is performed. However, the attribute and size constraints are still enforced. LockPolicy field is size 0. -- `VARIABLE_POLICY_TYPE_LOCK_NOW` -- means that the variable starts being locked +- `VARIABLE_POLICY_TYPE_LOCK_NOW` -- means that the variable starts being locked immediately after policy entry registration. If the variable doesn't exist at this point, being LockedNow means it cannot be created on this boot. LockPolicy field is size 0. -- `VARIABLE_POLICY_TYPE_LOCK_ON_CREATE` -- means that the variable starts being locked +- `VARIABLE_POLICY_TYPE_LOCK_ON_CREATE` -- means that the variable starts being locked after it is created. This allows for variable creation and protection after LockVariablePolicy() function has been called. The LockPolicy field is size 0. -- `VARIABLE_POLICY_TYPE_LOCK_ON_VAR_STATE` -- means that the Variable Policy Engine will +- `VARIABLE_POLICY_TYPE_LOCK_ON_VAR_STATE` -- means that the Variable Policy Engine will examine the state/contents of another variable to determine if the variable referenced in the policy entry is locked. @@ -254,14 +252,14 @@ considered inactive. Two types of wildcards can be used in the UEFI variable name field in a policy entry: -1. If the Name is a zero-length array (easily checked by comparing - fields `Size` and `OffsetToName` -- if they're the same, then the - `Name` is zero-length), then all variables in the namespace specified - by the provided GUID are targeted by the policy entry. -2. Character "#" in the `Name` corresponds to one numeric character - (0-9, A-F, a-f). For example, string "Boot####" in the `Name` - field of the policy entry will make it so that the policy entry will - target variables named "Boot0001", "Boot0002", etc. +1. If the Name is a zero-length array (easily checked by comparing + fields `Size` and `OffsetToName` -- if they're the same, then the + `Name` is zero-length), then all variables in the namespace specified + by the provided GUID are targeted by the policy entry. +2. Character "#" in the `Name` corresponds to one numeric character + (0-9, A-F, a-f). For example, string "Boot####" in the `Name` + field of the policy entry will make it so that the policy entry will + target variables named "Boot0001", "Boot0002", etc. Given the above two types of wildcards, one variable can be targeted by more than one policy entry, thus there is a need to establish the @@ -288,15 +286,21 @@ directory). ### Host-Based Unit Test -There is a test that can be run as part of the Host-Based Unit Testing -infrastructure provided by EDK2 PyTools (documented elsewhere). It will test -all internal guarantees and is where you will find test cases for most of the -policy matching and security of the Variable Policy Engine. +MU_CHANGE + +This test: + +`MdeModulePkg\Library\VariablePolicyLib\VariablePolicyUnitTest\VariablePolicyUnitTest.inf` + +can be run as part of the Host-Based Unit Testing infrastructure provided by EDK2 +PyTools (documented elsewhere). It will test all internal guarantees and is +where you will find test cases for most of the policy matching and security of the +Variable Policy Engine. ### Shell-Based Functional Test -This test -- [Variable Policy Functional Unit Test](https://github.com/microsoft/mu_plus/tree/release/202005/UefiTestingPkg/FunctionalSystemTests/VarPolicyUnitTestApp) -- can be built as a -UEFI Shell application and run to validate that the Variable Policy Engine +This test -- [Variable Policy Functional Unit Test](https://github.com/microsoft/mu_plus/tree/release/202005/UefiTestingPkg/FunctionalSystemTests/VarPolicyUnitTestApp) +-- can be built as a UEFI Shell application and run to validate that the Variable Policy Engine is correctly installed and enforcing policies on the target system. NOTE: This test _must_ be run prior to calling `DisableVariablePolicy` for all @@ -321,8 +325,8 @@ the variable, appropriate GUID listed as the namespace, and 1 as value. Entry into the trusted UEFI menu app doesn't signal ReadyToBoot, but booting to any device does, and the setup variables are write-protected. The "ReadyToBoot" variable would need to be -locked-on-create. *(THIS IS ESSENTIALLY LOCK ON EVENT, BUT SINCE THE -POLICY ENGINE IS NOT IN THE UEFI ENVIRONMENT VARIABLES ARE USED)* +locked-on-create. _(THIS IS ESSENTIALLY LOCK ON EVENT, BUT SINCE THE +POLICY ENGINE IS NOT IN THE UEFI ENVIRONMENT VARIABLES ARE USED)_ For example, "AllowPXEBoot" variable locked by "ReadyToBoot" variable.