06 Aug 14:22

github-actions

f0c8e10

v2023110002.0.1

What's Changed

Add debug level prefix for advanced logger memory message entries - Driver implementation @liqiqiii (#525)
Change Details
## Description
Add debug level prefix for advanced logger memory message entries - Driver implementation
This change added the existing metadata - debug level into the final
advanced logger memory entries through AdvancedFileLogger. This is a followup PR for 243bd18.
After this PR checked in, we can easily track the DEBUG_ERRORs through advanced logger files on UEFI that included this driver.
Added an extra space in the decodeuefilog.py to improve readability of the log.
For the for loop in the code, ran with perf_trace enabled, and influence is very low and can be ignored.
Updated the prefix of python script to match the design here.
Use [ERROR] instead of [DEBUG_ERROR], which could save overall log file sizes and memory buffer usage.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested with two platforms that uses AdvancedFileLogger and can see debug level
prefixes in the logs in the EFI Partition and USB UefiLogs folder.
[MM_CORE] [ERROR] Image - MmSupervisorCore.pdb

Integration Instructions

N/A

Full Changelog: v2023110002.0.0...v2023110002.0.1

Contributors

liqiqiii

Assets 2

16 Jul 14:31

github-actions

v2023110001.0.3

243bd18

v2023110001.0.3

What's Changed

Add debug level prefix for advanced logger memory message entries @liqiqiii (#523)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change added the existing metadata - debug level into the final advanced logger memory entries, it can differentiate the different debug levels, DEBUG_INFO, DEBUG_ERROR, etc.
We don't need to touch firmware as debug level info is already part of metadata, so we only need to update the decode script.
It's useful to be able to filter out the specific debug level msgs that we care about and make data processing of uefi logs possible.
For example, DEBUG_ERROR level prints are generally very important and worth analyzing. One blocking thing now is that we can't tell the difference between different debug level msgs because not all DEBUG_ERROR will have an "error:" as the prefix of the debug msg, and search for "error" will also be noisy as it's a commonly used word. After this PR checked in, we can easily track the DEBUG_ERRORs.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested with a platform that uses advancedlogger and can seedebug level prefixes in the msg.
22:36:22.840 : [MM_CORE] [DEBUG_INFO]AdvancedLoggerGetLoggerInfo: LoggerInfo=70F37000
22:36:22.857 : [MM_CORE] [DEBUG_ERROR]ERROR - The FV at 0xFFE60000 is invalid!

Integration Instructions

N/A

Full Changelog: v2023110001.0.2...v2023110001.0.3

Contributors

liqiqiii

Assets 2

13 Jul 18:28

github-actions

v2023110001.0.2

877bd3f

v2023110001.0.2

What's Changed

MfciPkg: Removed TargetVerifyPhaseSuite Tests suite since it did not contain any tests. @apop5 (#522)
Change Details
## Description
MfciVerifyPolicyAndChangeRoTHostTest.c and MfciVerifyPolicyAndChangeHostTest.c both contained an additonal registered test suite that did not contain any tests.

MsWheaPkg also contained a test suite where the tests associated were not registered correctly.

This started failing after fd8a09795aa where empty test suites will now be reported as an error.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Local CI passed after change.

Integration Instructions

N/A

AdvLoggerPkg: Remove NVMe Check from File Logger File Creation @os-d (#517)
Change Details
## Description
Currently, File Logger will only create the UefiLogs directory on the ESP if the device is an NVMe device. This is an unneccesary restriction and is removed in this patch.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested on a system with a non-NVMe drive that failed to have the FileLogger directory created before this change and succeeds now.

Integration Instructions

If the integrating platform has a filesystem that does not support being logged to, it should set PcdAdvancedFileLoggerForceEnable to FALSE so that the directory is not attempted to be created.

Apply more idiomatic Rust patterns in RustAdvancedLoggerDxe @magravel (#498)
Change Details
## Description
Use more idiomatic rust pattern and remove the explicitly implementation of Sync and Send since these traits are automatically implemented.

Note: changes in pointer.rs are cause by cargo fmt
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Ran cargo make test

Integration Instructions

N/A

MfciPkg \& MsCorePkg: Fix unit test compilation errors. @apop5 (#505)
Change Details
## Description
Unit tests started failing due to compilation errors. This stemmed from a bug fixed in microsoft/mu_basecore#891. Once this bug was fixed, the unit tests starting to be compiled which blocked pipelines.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Ran Local CI to verify unit tests change.

Integration Instructions

N/A

Add support for Digitizer touch input usages as pointer buttons @joschock (#496)
Change Details
## Description
This PR adds support for Digitizer switch usages (HID Usage Page 0xD, usages 0x42 through 0x46) as buttons in the AbsolutePointer implementation.

See https://usb.org/document-library/hid-usage-tables-15 for usage tables.
- Impacts functionality?
  - Add support for Digitizer switch usages as buttons in the pointer interface.
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Functionally verified with a touch panel implementation that exposes these HID usages.

Integration Instructions

No special integration required.
```
  </blockquote>
  <hr>
</details>
```

Fixing precedence of "not" and bitwise operators @kuqin12 (#497)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change fixed the incorrect precendence where the "not" operator will be evaluated before the bitwise operator.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

The test does not change result.

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

🔐 S...

Contributors

os-d, joschock, and 4 other contributors

Assets 2

06 Aug 14:21

github-actions

v2023020006.1.3

2603491

v2023020006.1.3

What's Changed

🐛 Bug Fixes

[REBASE \& FF] Advanced Logger Cherry-Picks From 202311 @os-d (#520)
Change Details
## Description
This PR cherry-picks one full commit and one very small part of another commit from 202311:

Remove NVMe Check from File Logger

This is a complete cherry-pick from c024ed1. It adds support for File Logger to create the UefiLogs directory on non-NVMe devices.

Allocate AdvLogger Pre-Mem Pages as EfiBootServicesData

This is a part of be9a3d2. The rest of this commit is not taken because it is a new feature (a new version of the AdvLogger structure). This portion of the commit was taken because it is a bugfix for when ARM64 switched over to 64k runtime page allocation granularity. Because PeiCore has a hardcoded assumption it is operating pre-mem, which is not true for ARM64, we cannot allocate a minimum of 16 pages for a runtime type at the start of PeiCore (when AdvLogger is initialized there). We instead need to allocate as EfiBootServicesData (which does not have the runtime page allocation granularity) and reallocate as EfiRuntimeServicesData after permanent memory is installed.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

N/A

Integration Instructions

N/A

Full Changelog: v2023020006.1.2...v2023020006.1.3

Contributors

os-d

Assets 2

05 Jun 22:24

github-actions

v2023110001.0.1

0a1ce57

v2023110001.0.1

What's Changed

Fixing uninitialized variable used in AdvLoggerOsConnectorPrmConfigLib @kuqin12 (#495)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

This change fixes an code path when the error occurs early enough, the Status might get evaluated without being initialized.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

This is tested building with CLANGPDB. The build failure is gone after the fix.

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

Fix GCC Build of AdvLoggerOsConnectorPRM @os-d (#494)
Change Details
## Description
The GCC build options in the INF referenced a function in the sample PRM driver (and was apparently not caught by CI). Building on GCC breaks without this function defined. Instead require that the PRM handler is defined (so that GCC does not strip it out when building the binary, seeing it not being referenced).

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Building on GCC.

Integration Instructions

N/A.
```
  </blockquote>
  <hr>
</details>
```

Update MorLockTestApp to fix errors with new standard return values @Ken-Pong (#488)
Change Details
## Description
When TcgMorLockSmm.c the SetVariableCheckHandlerMorLock() function was changed to set the MorLock variable Value to 0x01 to indicate Locked Without Key, MorLockTestApp also need to be changed to make sure the test flow can get positive results.

Changes are listed as below
1. MorLockShouldNotBeSet(): This function should compare with MOR_LOCK_DATA_UNLOCKED.
2. MorLockv2LockedWithoutKeyShouldReportCorrectly(): Rename from MorLockv2ShouldReportCorrectly() and update usage in MorLockTestApp() as it is compared with MOR_LOCK_DATA_LOCKED_WITHOUT_KEY.
3. MorLockv2LockedWithKeyShouldReportCorrectly(): This new function compares MorLock with MOR_LOCK_DATA_LOCKED_WITH_KEY for Morlock V2 testing. Also update usage in MorLockTestApp().
4. MorLockv2ShouldNotClearWithWrongKey(): Should compare with MOR_LOCK_DATA_LOCKED_WITHOUT_KEY when using wrong key to clear MorLock.
5. MorLockv2ShouldSetClearSet(): Should compare with MOR_LOCK_DATA_LOCKED_WITHOUT_KEY when using different key to clear MorLock.
6. MorLockTestApp(): Update above function usage in different test cases to make sure the test can be finished.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested in the uefi shell. The tests should get positive results and no errors are reported.

Integration Instructions

N/A

🐛 Bug Fixes

Fixing bsr64 for MathLib @kuqin12 (#492)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

When using GCC(-like) compilers to build MathLib, the sqrt_d function will use built-in functions for bit scan reverse. However, the calculation for 64 bit BSR is incorrectly using the built-in function specifically for unsigned long, which is 32-bit for CLANGPDB and cause the unit test to fail.

This change fixed the built-in function usage.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Unit test passed on QEMU SBSA platform built with CLANGPDB.

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

Full Changelog: v2023110001.0.0...v2023110001.0.1

Contributors

os-d, kuqin12, and Ken-Pong

Assets 2

27 Apr 00:20

github-actions

v2023110000.0.6

da051c7

v2023110000.0.6

What's Changed

Relax report length requirements @joschock (#455)
Change Details
## Description
This PR brings in two fixes to support a wider variety of devices, some of which might not be completely self-consistent:
- Allow report lengths that don't match the report descriptor. Reports that are shorter than the Report Descriptor specifies will be processed for whatever fields are fully present. Reports that are longer than the Report descriptor specifies will simply ignore the extra bytes in the report.
- Move away from using signal_event to force keyboard layout initialization, and install call the layout change routine directly. This avoids introducing sequencing issues based on the TPL that the keyboard is being initialized at, resulting in more deterministic behavior.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Rust unit tests updated to cover new functionality all pass. Functional testing on hardware with the changes also passes.

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

📖 Documentation Updates

Moving the global variable from header file into library instances @kuqin12 (#473)
Change Details
## Description
The current implementation of instantiating global variables will make each c file that includes this header to carry a copy of such variable, which is space redundant.

This change removed the variable into the single module that uses it and removed the structure it defines. The function descriptions are also updated.
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

This is a non-functional change.

Integration Instructions

N/A

Full Changelog: v2023110000.0.5...v2023110000.0.6

Contributors

joschock and kuqin12

Assets 2

17 Apr 20:47

github-actions

v2023110000.0.5

b748acb

v2023110000.0.5

What's Changed

Put log entries into HOBs in PEI during log buffer initialization @kuqin12 (#466)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

The current implementation will directly allocation pages through PEI services when Advanced logger is not initialized. This cause an issue of permanent loop if/when there are prints from the allocation routine.

This change will create a hob during this interim state and log messages to hobs temporarily and coalesce the hobs after the allocation is finalized. This will reduce the print restriction down to hob creation only.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

This is tested on QEMU SBSA as well as Q35. Both booted to UEFI shell.

Integration Instructions

N/A
```
  </blockquote>
  <hr>
</details>
```

Update the Mem Map and MAT Shell Test to Support RUNTIME\_PAGE\_ALLOCATION\_GRANULARITY Alignment @os-d (#460)
Change Details
## Description
The Mem Map and MAT shell test currently has a hard dependency on 4k alignment of EFI_MEMORY_MAP and MAT table entries. This is only valid when the RUNTIME_PAGE_ALLOCATION_GRANULARITY is 4k. To make this more universal, compare the MAT entries to RUNTIME_PAGE_ALLOCATION_GRANULARITY as well as the UEFI spec defined EFI_MEMORY_MAP types that should have RUNTIME_PAGE_ALLOCATION_GRANULARITY.

As a small cleanup, rename LegacyMemoryMap to EfiMemoryMap as it is certainly not legacy and to avoid confusion :).

This also removes a duplicate test.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Tested by running the shell app on Q35 and confirming it still succeeds.

Integration Instructions

N/A. This has no dependency on mu_basecore 64k changes because the RUNTIME_PAGE_ALLOCATION_GRANULARITY is what we expect the MAT and runtime EFI_MEMORY_MAP entries to be aligned to, regardless of whether that is 4k or 64k.
```
  </blockquote>
  <hr>
</details>
```

[REBASE \&\& FF] Documentation Updates to Paging Audit @TaylorBeebe (#459)

Change Details

This PR updates the documentation of the SMM and DXE paging audits to reflect recent changes and describe usage.
This PR also removes the AllocatedPagesAndPoolsAreProtected test because it is not required according to the Enhanced Memory Protection spec and a similar test is run in the DxeMemoryProtectionTestApp. The NullCheck test is renamed to better reflect purpose.

📖 Documentation Updates

Advanced Logger Binary Dump Windows Executable @VivianNK (#453)
Change Details
## Description
Console app to get Advanced Logger dump.

For each item, place an "x" in between [ and ] if true. Example: [x].
(you can also check items in the GitHub UI)
- Impacts functionality?
  - Functionality - Does the change ultimately impact how firmware functions?
  - Examples: Add a new library, publish a new PPI, update an algorithm, ...
- Impacts security?
  - Security - Does the change have a direct security impact on an application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- Breaking change?
  - Breaking change - Will anyone consuming this change experience a break
    in build or boot behavior?
  - Examples: Add a new library class, move a module to a different repo, call
    a function in a new library class in a pre-existing module, ...
- Includes tests?
  - Tests - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [ x] Includes documentation?
  - Documentation - Does the change contain explicit documentation additions
    outside direct code modifications (and comments)?
  - Examples: Update readme file, add feature readme file, link to documentation
    on an a separate Web page, ...
How This Was Tested

Built and ran on ARM and x64 machines. Verified output was identical to DecodeUefiLog script raw dump.

Integration Instructions

N/A

Full Changelog: v2023110000.0.4...v2023110000.0.5

Contributors

VivianNK, os-d, and 2 other contributors

Assets 2

Releases: microsoft/mu_plus

v2023110002.0.2

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023110002.0.1

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023110002.0.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

⚠️ Breaking Changes

How This Was Tested

Integration Instructions

🐛 Bug Fixes

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.3

What's Changed

Description

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.2

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Description

How This Was Tested

Integration Instructions

🔐 S...

Contributors

v2023020006.1.3

What's Changed

🐛 Bug Fixes

Remove NVMe Check from File Logger

Allocate AdvLogger Pre-Mem Pages as EfiBootServicesData

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.1

What's Changed

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🐛 Bug Fixes

Description

How This Was Tested

Integration Instructions

Contributors

v2023110001.0.0

What's Changed

How This Was Tested

Integration Instructions