23 Aug 22:27

github-actions

3ab3d78

v2022080002.1.3

What's Changed

[CHERRY-PICK] [202208] SpellCheck: force no color codes @Javagedes (#531)
Change Details
## Description
The SpellCheck plugin runs cspell, which uses ANSI color codes when displaying results. When ANSI color codes are used in a terminal that does not support ANSI, the color codes are displayed as text, which causes the rest of SpellCheck plugin to fail as the expected path is not a real path as it starts and ends with color codes:

i.e. \�[90m.\Path\To\File.txt�[39m instead of .\Path\To\File.txt

This change forces cspell to not colorize the output.
- 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

CI

Integration Instructions

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

Full Changelog: v2022080002.1.2...v2022080002.1.3

Contributors

Javagedes

Assets 3

15 Aug 16:27

github-actions

v2023020002.2.0

14eb9e3

v2023020002.2.0

What's Changed

Use gMuEventPreExitBootServicesGuid for SnpDxe to issue PxeShutdown @JoeLopez333 (#522)
Change Details
## Description Fixes https://github.com//issues/520
SnpDxe registers for an ExitBootServices callback and runs the PXE_OPCODE_SHUTDOWN and PXE_OPCODE_STOP commands for any network controllers that the driver is attached to. If the Bus Master Enable bit is cleared by PciBusDxe before this point, then completions returned by the network cards will be unreadable to their drivers during the shutdown sequence.

Register the SnpDxe callback for gMuEventPreExitBootServicesGuid instead of gEfiEventExitBootServicesGuid to ensure the correct ordering:
1. ExitBootServices event
2. Network card shutdown sequence is completed
3. BME is disabled on PCI bridges (if configured)
- 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

verified on ARM platform with two network cards

Integration Instructions

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

MdeModulePkg/NvmExpressDxe: Add robustness changes with rebase [Rebase \& FF] @makubacki (#523)
Change Details
## Description
PR #516 was accidentally squashed instead of rebased. For future source
history clarity, this PR replaces that with the rebased set of commits.

The actual content remains the same.
- 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

WinRcPath: improve performance @Javagedes (#512)
Change Details
## Description
WinRcPath generally takes about 2 seconds to run, due to calling multiple .bat files behind the scenes. This change reduces this time to ~0 seconds due to the following changes:
1. It will attempt to load the path from the cache, which is located a $(WORKSPACE)/Conf/.rc_path. If the loading is a success and the rc_path still exists, it will use it.
2. If the cache did not exist, or the path provided by the cache does not exist, it will find the rc path via the .bat files. If that succeeds, it will write the path to the cache.
- 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
1. Confirmed the plugin will create a cache file on first run and use it in later runs
2. Confirmed updating the path in the cache to a wrong value will invoke the typical means to find the cache and save the correct path into the cache
Integration Instructions

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

FlattenPdbs: improve performance @Javagedes (#511)
Change Details
## Description
FlattenPdbs generally takes anywhere from .8 to 1.5 seconds for a given platform. This change reduces this time to .3 to .4 seconds due to the following changes:
1. Only copy pdbs in the the OUTPUT folder. The original code did not check what folder the pdb was in, and would copy the same pdb multiple times due to the same file siting in OUTPUT and DEBUG folders.
2. Performs a hardlink rather than copying the file. This improves performance as a hardlink is treated as it's own file, but points the same physical file on disk. This means we create just the file metadata, and don't need to copy the data the file contains. A reference counter ensures that deleting the file in one place does not not delete the file on disk (unless it is the last reference), so the other hardlinks are not affected.
3. The above change also allows the code to check the ino value (a unique identifier for a file on disk) and skip the making of a hardlink if it is already linked. This is a small optimization as running a build only rebuilds modules that have changed.
- 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
1. Verified performance improvements
2. Verified non-changed files are not copied to the bdb folder
3. verified changed files are copied to the pdb folder
4. Verified files deleted in the pdb folder are replaced
Integration Instructions

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

Set OpenCppCoverage working dir to avoid files in root @cfernald (#507)
Change Details
## Description
Set the working dir for OpenCppCoverage. OpenCppCoverage will ALWAYS create a file called LastCoverageResults.log in it's current working directory, regardless of it's working_dir parameter. This change makes sure this file is opened in the build dir instead.
- Impacts functionality?
- Impacts security?
- Breaking change?
- Includes tests?
- Includes documentation?
How This Was Tested

Tested with local builds
...

Contributors

cfernald, makubacki, and 2 other contributors

Assets 4

28 Jul 14:54

github-actions

v2023020002.1.5

41f615f

v2023020002.1.5

What's Changed

Update IORT SMMUv3 IORT node flags for HTTU to include dirty state support @JoeLopez333 (#500)
Change Details
# Preface
Please ensure you have read the contribution docs prior
to submitting the pull request. In particular,
pull request guidelines.

Description

Fixes #498

The flag for HTTU override in an SMMUv3 node in the IORT table is currently define in MU_BASECORE/MdePkg/Include/IndustryStandard/IoRemappingTable.h:63 as:
```
#define EFI_ACPI_IORT_SMMUv3_FLAG_HTTU_OVERRIDE     BIT1
```
The length of this field is actually 2 bits. Possible values are:

0b0000: Hardware update of the Access flag and dirty state are not supported.
0b0001: Support for hardware update of the Access flag for Block and Page descriptors.
0b0010: As 0b0001, and adds support for hardware update of the Access flag for Block and Page descriptors. Hardware update of dirty state is supported.

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 on Arm64 platform

Integration Instructions

update flags in IORT table if consuming this flag definition

BaseTools: Detect library class mismatch [REBASE\&FF] @Javagedes (#499)
Change Details
## Description Performs a check that will verify that the library instance implements the specified library by ensuring a LIBRARY_CLASS definition exists in the INF [Defines] section matches the library.
That is to say, for the following example:
TestLib|Path/To/BaseTestLib.inf, that BaseTestLib.inf has
LIBRARY_CLASS = TestLib defined in the [Defines] section.

Changes the previous check for library overrides to be a warning instead
of 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

Built multiple platforms to confirm warning showed properly.

Integration Instructions

While no Integration is required, a new build warning will be seen in the build log. The warning is in the following format:
$(DSC_PATH): warning: $(INF) does not support LIBRARY_CLASS $(LIBRARY_CLASS) where $(DSC_PATH) is the DSC being built, $(INF) is the INF described in the DSC, and $(LIBRARY_CLASS) is the name of the library class that the INF is attempting to represent. (i.e., $(LIBRARY_CLASS)|$(INF) or TestLib|Path\to\BaseTestLib.inf).

To resolve these errors, verify the library class is real (The Library class should have a header file associated with it in the DEC of the defining package). If it is real, then ensure the library instance truly implements the library class and add it to the DEFINE section of the library INF. If not, update the DSC to use the correct library class.

If this warning appears, it will appear at the beginning of the build command:
INFO - Processing meta-data .
INFO - Architecture(s) = IA32 X64
INFO - Build target = DEBUG
INFO - Toolchain = VS2022
INFO -
INFO - Active Platform = c:\src\Path\Platform.dsc
INFO - build...
INFO - c:\src\Path\Platform.dsc(...): warning: c:\src\Path\BaseTestLib.inf does not support LIBRARY_CLASS TestLib

🔐 Security Impacting

CryptEc.c CodeQL Fix @TaylorBeebe (#492)
Change Details
## Description
Free calls could have been called with NULL arguments.
- 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 Q35

Integration Instructions

N/A

Full Changelog: v2023020002.1.4...v2023020002.1.5

Contributors

Javagedes, TaylorBeebe, and JoeLopez333

Assets 4

18 Jul 21:44

github-actions

v2023020002.1.4

4a53c6a

v2023020002.1.4

What's Changed

Revert "Stop USB enumeration in case a malformed descriptor is found (#410)" @makubacki (#493)
Change Details
## Description
This reverts commit 714d41b.

Some devices are dependent on this functionality and can be important
sources of input during boot. Until a more robust solution is devised
that can support these devices, this change is reverted.
- 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

Verified a USB mass storage device that failed to enumerate with
the change can be enumerated after reverting it.

Integration Instructions

N/A

Full Changelog: v2023020002.1.3...v2023020002.1.4

Contributors

makubacki

Assets 4

18 Jul 21:45

github-actions

v2022080002.1.2

b21ddf6

v2022080002.1.2

What's Changed

Revert "Stop USB enumeration in case a malformed descriptor is found (#410)" @makubacki (#494)
Change Details
## Description
This reverts commit 714d41b.

Some devices are dependent on this functionality and can be important
sources of input during boot. Until a more robust solution is devised
that can support these devices, this change is reverted.
- 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

Verified a USB mass storage device that failed to enumerate with
the change can be enumerated after reverting it.

Integration Instructions

N/A

Full Changelog: v2022080002.1.1...v2022080002.1.2

Contributors

makubacki

Assets 3

14 Jul 16:03

github-actions

v2023020002.1.3

3f022da

v2023020002.1.3

What's Changed

🐛 Bug Fixes

Refactoring infinite boot option retries @apop5 (#392)
Change Details
## Description
Last revision of infinite boot retries resulted in build errors with VS2022 due to "unreachable code" errors.

Refactor to move loop to top level function. Refactor of #347

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

Build with VS2022 and PcdSupportInfiniteBootRetries set to TRUE.
Build with VS2022 and PcdSupportInfiniteBootRetries set to FALSE.
Build with GCC5 and PcdSupportInfiniteBootRetries set to TRUE.

Integration Instructions

N/A

🔐 Security Impacting

Fix CodeQL errors @kenlautner (#490)
Change Details
## Description
Fixed some CodeQL failures we're seeing in a variety of packages. This takes the changes from the PR found here and builds upon them.
- 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 through CodeQL checks.

Integration Instructions

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

Full Changelog: v2023020002.1.2...v2023020002.1.3

Contributors

kenlautner and apop5

Assets 4

14 Jul 16:03

github-actions

v2022080002.1.1

70a4fa5

v2022080002.1.1

What's Changed

[CHERRY-PICK]: MdeModulePkg/BdsDxe/BaseEntry.c Refactoring infinite boot option retries (#392) @apop5 (#487)
Change Details
## Description
Last revision of infinite boot retries resulted in build errors with VS2022 due to "unreachable code" errors.

Refactor to move loop to top level function. Refactor of #347

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

Build with VS2022 and PcdSupportInfiniteBootRetries set to TRUE. Build with VS2022 and PcdSupportInfiniteBootRetries set to FALSE. Build with GCC5 and PcdSupportInfiniteBootRetries set to TRUE.

Integration Instructions

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

🔐 Security Impacting

Fix CodeQL errors @kenlautner (#488)
Change Details
## Description
Fixed some CodeQL failures we're seeing in a variety of packages.
- 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 through CodeQL checks.

Integration Instructions

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

Full Changelog: v2022080002.1.0...v2022080002.1.1

Contributors

kenlautner and apop5

Assets 3

10 Jul 19:34

github-actions

v2023020002.1.2

fa1c617

v2023020002.1.2

What's Changed

Change default alignment for ramdisk booting. @ddeptford (#480)
Change Details
The ramdisk is modelled as an NVDIMM which have a naturally higher alignment than 4K. Operating systems may wish to map NVDIMMs using large pages, so force the allocation alignment to 2MB.
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?
  - Alignment of ramdisk is changed from 4KB to 2MB.
- 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 change was tested using HTTP ramdisk boot, targeting a flat windows image.

Integration Instructions

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

MdeModulePkg: PciHostBridgeDxe: ignore TypeIo @Javagedes (#482)
Change Details
## Description
Throughout PciHostBridgeDxe, functions iterate through all entries in the PCI_RESOURCE_TYPE enum. However TypeIo only applies for x86_64 platforms. This changes the starting point of the PCI_RESOURCE_TYPE enum loops from 0 to PCI_RESOURCE_TYPE_ENUM_START and conditionally sets that value to TypeIo or TypeMem32 based on if the platform is x86_64 or not.

closes #444
- 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

Will be platform tested

Integration Instructions

N/A

Full Changelog: v2023020002.1.1...v2023020002.1.2

Contributors

Javagedes and ddeptford

Assets 4

06 Jul 00:13

github-actions

v2022080002.1.0

1bebdd1

v2022080002.1.0

What's Changed

.github/release-draft.yml: Use Mu DevOps 5.0.4 @makubacki (#484)
Change Details
## Description
Updates the workflow to the latest Mu DevOps (v5.0.4)
to use the ReleaseDrafter.yml file in v5 that supports
N and N-1 branch support.
- 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

Mu Basecore fork.

Integration Instructions

N/A

TCBZ 4492: Update SplitTable() Logic to Correctly Break Up Memory Map Descriptors @TaylorBeebe (#476)
Change Details
## Description
Fixes #475

Fix the SplitTable() logic to correctly break up the memory map and fix errors in the Memory Attributes Table.
- 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 Q35

Integration Instructions

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

.github/label-issues.yml: Use Mu DevOps 4.0.5 @makubacki (#477)
Change Details
## Description
4.0.5 updates the GitHub Actions used for labeling to include a
bug fix for previous versions trying to delete a label that does not exist.
- 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

Already enabled in release/202302 and resolves a workflow error
encountered in the label task.

Integration Instructions

N/A - Integrated in this change

🚀 Features & ✨ Enhancements

MdeModulePkg/UefiBootManagerLib: Skip con var update if no change @makubacki (#445)
Change Details
## Description
MdeModulePkg/UefiBootManagerLib: Skip con var update if no change

Checks if the newly computed device path for a console variable is
different than the saved value before writing through UEFI variable
services.

This allows function callers to simplify their own logic around
reducing calls to EfiBootManagerUpdateConsoleVariable() and
overall prevents unnecessary writes to UEFI variables that may
not be necessary.
- 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

Verified console variables are updated when a new device path is
determined and the update is skipped when no change is made to the
device path already saved in the corresponding console UEFI variable.

Integration Instructions

N/A

Full Changelog: v2022080002.0.3...v2022080002.1.0

Contributors

makubacki and TaylorBeebe

Assets 3

06 Jul 00:13

github-actions

v2023020002.1.1

e741128

v2023020002.1.1

What's Changed

📖 Documentation Updates

CI: Add Rust Host Unit Test CI check @Javagedes (#481)
Change Details
## Description
Adds a CI plugin, RustHostUnitTestPlugin, with the scope rust-ci that runs all tests, ensuring they pass. If they pass, code coverage is calculated, which must meet the requirements specified in a package's ci.yaml file (default is 75% code coverage). Will generate a coverage.xml file in the Build directory.
- 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

Ensured Check can run successfully

Integration Instructions

Add the rust-ci scope to your settings python file for stuart_ci_build. add toml to your pip-requirements.txt file.

Full Changelog: v2023020002.1.0...v2023020002.1.1

Contributors

Javagedes

Assets 4

Releases: microsoft/mu_basecore

v2022080002.1.3

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020002.2.0

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

Contributors

v2023020002.1.5

What's Changed

Description

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2023020002.1.4

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2022080002.1.2

What's Changed

How This Was Tested

Integration Instructions

Contributors

v2023020002.1.3

What's Changed

🐛 Bug Fixes

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2022080002.1.1

What's Changed

How This Was Tested

Integration Instructions

🔐 Security Impacting

How This Was Tested

Integration Instructions

Contributors

v2023020002.1.2

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

Contributors

v2022080002.1.0

What's Changed

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

How This Was Tested

Integration Instructions

🚀 Features & ✨ Enhancements

How This Was Tested

Integration Instructions

Contributors

v2023020002.1.1

What's Changed

📖 Documentation Updates

How This Was Tested

Integration Instructions