Skip to content

Releases: microsoft/mu_basecore

v2023110001.1.0

22 Feb 18:29
d5379bd
Compare
Choose a tag to compare

What's Changed

  • RustEnvironmentCheck: Bugfix embedded quotes @Javagedes (#749)
    Change Details
      ## Description

    Replaces embedded double quotes with single quotes in the RustEnvironmentCheck plugin as embedded double quotes support when working with f-strings was only added in python 3.12, and this project should support python 3.10, 3.11, and 3.12.

    File "C:\src\mu_plus\MU_BASECORE\BaseTools\Plugin\RustEnvironmentCheck\RustEnvironmentCheck.py", line 259
        f"  cargo binstall cargo-make {('--version ' + tool_versions.get("cargo-make", "")) if "cargo-make" in tool_versions else ""}"
    
    SyntaxError: f-string: unmatched '('
    • 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 the plugin works on 3.10, 3.11, and 3.12

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    

🚀 Features & ✨ Enhancements

  • Edk2ToolsBuild: override basetoolsbin\_ext\_dep @Javagedes (#745)
    Change Details
      ## Description

    Building a local copy of Edk2ToolsBuild does not automatically override the pre-compiled copy of the basetools provided by basetoolsbin_ext_dep.

    This commit adds an id to the external dependency, that can then be overridden with override_id in the path_env file that is generated when you build the basetools locally with Edk2ToolsBuild.

    • 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 EDK_TOOLS_BIN now points at the locally-built basetools once they have been built.

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    

Full Changelog: v2023110001.0.3...v2023110001.1.0

v2023110001.0.3

21 Feb 03:45
35d06ff
Compare
Choose a tag to compare

What's Changed

  • remove edk2-basetools @Javagedes (#732)
    Change Details
      ## Description

    Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as it is managed by Project Mu) that is not available in edk2-basetools.

    • 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 the build system continues to use the local python source

    Integration Instructions

    N/A - only effects this repository's CI system.




  • RustEnvironmentCheck: Check Version if specified @Javagedes (#737)
    Change Details
      ## Description

    Allows repository owners to enforce version requirements for some rust related tools needed for build. This includes cargo-make and cargo-tarpaulin.

    RustEnvironmentCheck currently only checks that the necessary tooling exists on the system. The only version check it performs is for the compiler version. This update adds support for repository owners to optionally require specific versions for cargo-make and cargo-tarpaulin by setting the required version in the rust-toolchain.toml file at the workspace root.

    Updates the install command suggestion for cargo make and cargo tarpaulin.

    Example Usage:

    # rust-toolchain.toml
    [toolchain]
    channel = "1.73.0"
    
    [tool]
    cargo-tarpaulin = "0.27.3"
    cargo-make = "0.37.9"
    
    • 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

    Confirmed the following scenarios:

    1. Tool missing, version specified
      image
    2. Tool missing, version not specified
      image
    3. Tool installed, version mismatch
      image

    Integration Instructions

    Example Usage:

    [toolchain]
    channel = "1.73.0"
    
    [tool]
    cargo-tarpaulin = "0.27.3"
    cargo-make = "0.37.9"
    

    If a repository maintainer wants to manage the version, update the rust-toolchain.toml file similar to the example aove.




🐛 Bug Fixes

  • BaseTools/RustEnvironmentCheck: Allow no tools in toolchain file @makubacki (#746)
    Change Details
      ## Description

    The get_required_tool_versions() function currently assumes that a
    tool match will be present in the workspace toolchain file. This
    change prevents a NoneType AttributeError if no results are found
    by first checking that match is not None.

    • 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

    • Run against rust-toolchain.toml file with a matching tool pattern
    • Run against rust-toolchain.toml file without a matching tool pattern

    Integration Instructions

    N/A




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

v2023020013.1.4

16 Feb 15:11
f44f0fe
Compare
Choose a tag to compare

What's Changed

🔐 Security Impacting

  • [Release/202302] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#739)
    Change Details
      # Preface

    Description

    This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.

    • 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?
      • Yes Patches the following CVEs:
        • CVE-2023-45229
        • CVE-2023-45230
        • CVE-2023-45231
        • CVE-2023-45232
        • CVE-2023-45233
        • CVE-2023-45234
        • CVE-2023-45235
    • Breaking change?
      • No
    • Includes tests?
      • Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
    • Includes documentation?
      • Yes - SecurityFixes.yaml explains which CVEs have been patched

    How This Was Tested

    Unit Tests / PxeBoot on real hardware

    Integration Instructions

    Take these changes if a merge conflict occurs




📖 Documentation Updates

  • [Release/202302] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#739)
    Change Details
      # Preface

    Description

    This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.

    • 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?
      • Yes Patches the following CVEs:
        • CVE-2023-45229
        • CVE-2023-45230
        • CVE-2023-45231
        • CVE-2023-45232
        • CVE-2023-45233
        • CVE-2023-45234
        • CVE-2023-45235
    • Breaking change?
      • No
    • Includes tests?
      • Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
    • Includes documentation?
      • Yes - SecurityFixes.yaml explains which CVEs have been patched

    How This Was Tested

    Unit Tests / PxeBoot on real hardware

    Integration Instructions

    Take these changes if a merge conflict occurs




Full Changelog: v2023020013.1.3...v2023020013.1.4

v2023110001.0.2

16 Feb 15:11
edb5903
Compare
Choose a tag to compare

What's Changed

🔐 Security Impacting

  • [Release/202311] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#738)
    Change Details
      # Preface

    Description

    This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.

    • 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?
      • Yes Patches the following CVEs:
        • CVE-2023-45229
        • CVE-2023-45230
        • CVE-2023-45231
        • CVE-2023-45232
        • CVE-2023-45233
        • CVE-2023-45234
        • CVE-2023-45235
    • Breaking change?
      • No
    • Includes tests?
      • Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
    • Includes documentation?
      • Yes - SecurityFixes.yaml explains which CVEs have been patched

    How This Was Tested

    Unit Tests / PxeBoot on real hardware

    Integration Instructions

    Take these changes if a merge conflict occurs




📖 Documentation Updates

  • [Release/202311] Cherry-Picks PixieFail vulnerability fixes for Bugs 1-7 @Flickdm (#738)
    Change Details
      # Preface

    Description

    This integrates fixes for bugs 1-7 for the PixieFail NetworkPkg vulnerabilities into mu_basecore.

    • 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?
      • Yes Patches the following CVEs:
        • CVE-2023-45229
        • CVE-2023-45230
        • CVE-2023-45231
        • CVE-2023-45232
        • CVE-2023-45233
        • CVE-2023-45234
        • CVE-2023-45235
    • Breaking change?
      • No
    • Includes tests?
      • Yes - provides unit tests to confirm the vulnerability has been fixed and backwards compatibility has been maintained
    • Includes documentation?
      • Yes - SecurityFixes.yaml explains which CVEs have been patched

    How This Was Tested

    Unit Tests / PxeBoot on real hardware

    Integration Instructions

    Take these changes if a merge conflict occurs




Full Changelog: v2023110001.0.1...v2023110001.0.2

v2023110001.0.1

15 Feb 21:32
76b62eb
Compare
Choose a tag to compare

What's Changed

  • CryptoPkg/RuntimeDxeCryptLib: Make globals static @makubacki (#741)
    Change Details
      ## Description

    The GNU linker (ld) raises an error due to duplicate symbols for the
    mVirtualAddressChangeEvent global. This change updates both globals
    in the file to be static to prevent future symbol collisions.

    • 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 VariableRuntimeDxe using GCC on Ubuntu with the RuntimeDxeCryptLib
      library instance linked.

    Integration Instructions

    N/A




  • BaseTools/GenFds: Resolve absolute workspace INF paths @makubacki (#740)
    Change Details
      ## Description

    Currently, if an INF path is an absolute path on Linux (begins with
    "/"), the "/" character will be removed. If the path is an absolute
    system path, this creates an invalid path.

    This creates an issue, for example, if an INF is in an ext dep where
    the ext dep has the set_build_var flag set and DSC files refer to
    files by its build variable (e.g. $(SHARED_CRYPTO_PATH)/Module.inf).

    $(SHARED_CRYPTO_PATH) will be an absolute path to the ext dep
    directory and FfsInfStatement.__InfParse__ will remove the leading
    "/" character so the path is invalid.

    This change first checks if the absolute path will resolve into the
    current workspace. If it does (as will happen in the shared crypto
    ext dep example above), it modifies the path to be relative to the
    workspace so later logic dependent on relative paths can operate on
    it. If the absolute path is not within the current workspace, it
    follows previous behavior for backward compatibility to that
    scenario.

    • 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 the change against Mu Basecore CI and Mu Tiano Platforms platform builds.
    • Build on Ubuntu with an ext dep that sets an absolute path in a build variable that
      is used to build an INF file. Verify failure before and success after the change.

    Integration Instructions

    N/A




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

v2023110001.0.0

15 Feb 14:46
0dd0d48
Compare
Choose a tag to compare

What's Changed

  • Remove static initialization of gMmst for MM Core Lib @cfernald (#730)
    Change Details
      ## Description

    Removes static initialization for gMmst in the MM Core implementation of MmServicesTableLib. Static initialization of this structure is problematic as callers will use the initialized value as a indication services are ready for use. This results in premature calls to memory allocations causing early faults in the core.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Tested boot with change.

    Integration Instructions

    N/A




⚠️ Breaking Changes

  • CryptoPkg/Driver: Remove directory @makubacki (#733)
    Change Details
      ## Description

    These contents will be available in the shared crypto binary.

    Quite a bit of the DSC is cleaned up to reflect the fact that the package is
    mostly just building libraries that wrap around PPIs and protocols now.

    • 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 files present in shared crypto external dependency in QemuQ35Pkg
      and QemuSbsaPkg.

    Integration Instructions

    Update any code to refer to the files relative to the shared crypto binary
    external dependency. Most references for shared crypto will be in files inside
    the shared crypto binary distribution package (ext dep).

    NOTE: The value BLD_*_SHARED_CRYPTO_PATH is different than the previous
    var_name value in the JSON file previously checked into this repo. This value
    can be used in build files and is more generic for the new use cases it serves.

    The ext dep also sits in CryptoPkg/Binaries a shorter, simpler path than
    before.




🚀 Features & ✨ Enhancements

  • CryptoPkg/Driver: Remove directory @makubacki (#733)
    Change Details
      ## Description

    These contents will be available in the shared crypto binary.

    Quite a bit of the DSC is cleaned up to reflect the fact that the package is
    mostly just building libraries that wrap around PPIs and protocols now.

    • 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 files present in shared crypto external dependency in QemuQ35Pkg
      and QemuSbsaPkg.

    Integration Instructions

    Update any code to refer to the files relative to the shared crypto binary
    external dependency. Most references for shared crypto will be in files inside
    the shared crypto binary distribution package (ext dep).

    NOTE: The value BLD_*_SHARED_CRYPTO_PATH is different than the previous
    var_name value in the JSON file previously checked into this repo. This value
    can be used in build files and is more generic for the new use cases it serves.

    The ext dep also sits in CryptoPkg/Binaries a shorter, simpler path than
    before.




  • .pytool/Plugin/DscCompleteCheck: Allow git ignore syntax @makubacki (#736)
    Change Details
      ## Description

    Allows ignore lines in the CI YAML file to use git ignore syntax.

    This is especially useful for ignore files recursively in directories
    like those that may exist in an external dependency folder.

    • 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

    • DSC Complete against all packages in Mu Basecore
    • DSC Complete against CryptoPkg ignoring shared crypto ext dep INFs
      with CryptoPkg/Binaries/**

    Integration Instructions

    Use the new syntax if beneficial in a platform.




  • CryptoPkg: Add RT DXE shared crypto library instance @makubacki (#731)
    Change Details
      ## Description

    Adds a new BaseCryptLibOnProtocolPpi instance that can be used by
    Runtime DXE drivers. For any other DXE modules types such as UEFI
    applications or not-RT DXE drivers, the existing DxeCryptLib should
    be used.

    • 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

    • CryptoPkg build and CI.
    • QemuQ35Pkg build and boot to Windows using the Runtime DXE variable driver
      with SMM_ENABLED=FALSE.

    Integration Instructions

    Use the RuntimeDxeCryptLib instance of BaseCryptLib if needed
    for RT DXE crypto support on a platform.




📖 Documentation Updates

  • .pytool/Plugin/DscCompleteCheck: Allow git ignore syntax @makubacki (#736)
    Change Details
Read more

v2023020013.1.3

15 Feb 14:48
69ca931
Compare
Choose a tag to compare

What's Changed

  • [CHERRY-PICK] Restore IntrinsicLib to CryptoPkg @kenlautner (#735)
    Change Details
      ## Description

    Some silicon code is making use of the CryptoPkg's Intrinsic lib.

    Intrinsiclib was removed in 04bb719.

    Adding the functionality back to allow silicon code to use the library while a better long term solution is created.

    • 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

    Integration Instructions

    N/A




Full Changelog: v2023020013.1.2...v2023020013.1.3

v2023110000.0.1

06 Feb 01:55
c6e7c62
Compare
Choose a tag to compare

What's Changed

🔐 Security Impacting

  • Updated Crypto binaries to 2023.02.9 to include SHA384 and SHA512 functions @kenlautner (#726)
    Change Details
      ## Description

    Built new binaries to include SHA384 and SHA512 functions in the STANDARD flavor of the crypto binary. This is to support new authenticated variable logic that allows you to choose which SHA functions to use instead of always using SHA256.

    • 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 QemuQ35 and on physical systems. SHA384 and SHA512 functions were usable.

    Integration Instructions

    Update your MU_BASECORE pin to include this change and it'll be pulled automatically.




Full Changelog: v2023110000.0.0...v2023110000.0.1

v2023110000.0.0

05 Feb 14:48
1d1fdbb
Compare
Choose a tag to compare

What's Changed

First 202311 Mu Basecore release 🎉.

  • Restore IntrinsicLib to CryptoPkg @apop5 (#712)
    Change Details
      ## Description

    Some silicon code is making use of the CryptoPkg's Intrinsic lib.

    Intrinsiclib was removed in afd1f31.

    Adding the functionality back to allow silicon code to use the library while a better long term solution is created.

    • 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

    Integration Instructions

    N/A




  • [Rebase \& FF] [Cherry-pick] Get all the missing commits from 202302 into 202311 @kenlautner (#721)
    Change Details
      ## Description

    Cherry-pick the commits from 202302 that are missing from 202311 since the creation of the release branch.

    • 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




  • release-basetools.yml: Add contents write permission for publishing @makubacki (#718)
    Change Details
      ## Description

    The GITHUB_TOKEN is used in the gh release upload command to
    upload a new basetools release. This adds content write permission
    to allow the upload to work when the default permission is read-only
    for the token.

    • 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 failure with read-only token on fork. Confirmed success with the change.

    Integration Instructions

    N/A - Only affects local repro GitHub workflow.




  • [CHERRY-PICK] Repo File Sync: Add permissions to GitHub workflows @makubacki (#719)
    Change Details
      ## Description

    Needed for GitHub workflows on this branch to continue functioning.

    (cherry picked from commit 8e5180d)

    • 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

    • release/202302 branch

    Integration Instructions

    N/A




  • Add SHA384 and SHA512 to the STANDARD flavor of the crypto binary @kenlautner (#709)
    Change Details
      ## Description

    Authenticated variables were updated to allow the choice of SHA256, SHA384 or SHA512 for hashing. To accommodate this change, we need the algorithms available for use. This change updates the STANDARD flavor of shared crypto to include the SHA384 and SHA512 algorithms so that they can be used by consumers of the binary.

    There is no size impact for the STANDARD flavor because all of the SHA implementations are built together in openssl. This simply enables their use.

    • 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 locally generated binaries. SHA384 and SHA512 were available to use.

    Integration Instructions

    N/A




  • [CHERRY-PICK] Remove requirements on `CRYPTO_SERVICES` and `ARCH` variables #710 @kuqin12 (#713)
    Change Details
      ## Description

    The original implementation of autogenerated dsc files is requiring platform owners to define all CRYPTO_SERVICES and ARCH variables when the dsc is included. This would require certain platforms, such as some AARCH64 platforms, to pull in unrelated library instances for BL32 or BL33 only builds.

    This change updated the ...

Read more

v2023020013.1.2

05 Feb 14:52
Compare
Choose a tag to compare

What's Changed

  • [CHERRY-PICK] release-basetools.yml: Add contents write permission for publishing @makubacki (#717)
    Change Details
      ## Description

    The GITHUB_TOKEN is used in the gh release upload command to
    upload a new basetools release. This adds content write permission
    to allow the upload to work when the default permission is read-only
    for the token.

    (cherry picked from commit 1cab22a)

    • 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 failure with read-only token on fork. Confirmed success with the change.

    Integration Instructions

    N/A - Only affects local repro GitHub workflow.




Full Changelog: v2023020013.1.1...v2023020013.1.2