Fixed Markdown errors MdeModulePkg

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.

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.