Skip to content

v1.7.1

Choose a tag to compare

View all tags
@mu-automation mu-automation released this 20 Oct 00:31
· 7 commits to refs/heads/main since this release
v1.7.1
daa3271
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

What's Changed

  • 9B release: bump bootmgfw svn to v11 olkorsha (#469)
    Change Details
      ## Description

    Keeping old DBXUpdateSVN.bin for backwards compat despite it now being insufficient, and adding 3 files:

    • dbx_SVN_Legacy.efiauth2: has the same contents of the existing DBXUpdateSVN.bin, however the file is slightly different due to being signed and generated later
    • dbx_SVN_bootmgfw_v11.efiauth2: signed by KEK 2011 and has bootmgr v11 SVN (01612B139DD5598843AB1C185C3CB2EB9200000B000000000000000000000000)
    • dbx_SVN.efiauth2: signed by KEK 2023 and has all the latest SVN values (bootmgr v11, cdboot v3, wdsmgfw v3

  • [Secure Boot KEK Update] Siemens PK-Signed KEK Update Dominik Wagner (@wagnerdo) (#402)
    Change Details
      ## OEM Certificate Submission

    OEM Name: Siemens AG
    Contact Email: wagner.dominik@siemens.com

    Certificate Details

    • Platform Key Thumbprint: 75d67554b3f49e3e83108c6daa067873dab65984
    • Expiration Date: 2042-04-19

    Testing Completed

    • Windows validation
    • Linux validation

    Security Review

    • No known security issues

    Additional Notes

    I am responsible for this submission, thus I have supplied my personal mail as contact Email.
    The official security contact is productcert@siemens.com

    Testing was performed with FW version V29.01.07.
    Windows: Windows 10 LTSC 2021 with BitLocker enabled using PowerShell as described in Wiki
    Linux: Ubuntu 22.04.1 LTS using efi-updatevar as described in Wiki



  • Remove check for existing boot.stl. Copy providing source exists. Res… Michael Madell (@michaelmadell) (#450)
    Change Details
      …ults in only requiring 2023 Certs in DB, having 2011 in DB is required for previous script.

    Description

    I have found that an ISO Passed through this script will still depend on the 2011 Certs in Secure Boot.
    I did some testing and found that the implementation of the boot.stl file is flawed, if the boot.stl already exists, which is the case for a Golden ISO downloaded from the MSFT website, it will not be overwritten and will depend on the 2011 certs being in the DB List.
    After changing that section a bit, removing the check for the destination boot.stl, causing an overwrite, results in the resulting ISO being bootable with the 2011 Certs in the DBX List, and only 2023 Certs in the DB List.

    For details on how to complete these options and their meaning refer to CONTRIBUTING.md.

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

    How This Was Tested

    1. Downloaded Windows 11 25H2 v2 ISO from MSFT Website.
    2. Ran it through previous script
    3. Attempted to boot installation media on a system with only the 2023 CA Certificates in the Secure Boot Database.
    4. Stopped as a Secure Boot violation message
    5. Removed the existing boot.stl check
    6. Ran ISO through updated script
    7. Attempted to boot installation media on a system with only the 2023 CA Certificates in the Secure Boot Database.
    8. Booted successfully to the Windows Setup Screen

    Integration Instructions

    Remove the check for the destination boot.stl file in the Make2023BootableMedia.ps1 script.

      </blockquote>
  <hr>
</details>
  • Restore KEK 2011 signed DBX binary paths that were recently removed, while flagging them for obsolescence Pete Batard (@pbatard) (#468)
    Change Details
      ## Description
    • The recent reorganisation of the signed DBX binaries in 92b433e had the unfortunate effect of breaking downstream workflows, that relied on the presence of the DXBUpdate.bin binaries in their previous location/names. This is discussed in #463 as well as pbatard/rufus#3039.
    • To give some time for these workflow to be updated, the KEK 2011 signed objects that existed at the time of the removal are restored, while being being flagged as obsolete and planned for deletion at a later date as it will not be updated further. In the depreciation notice we also point to using the new .auth2 binaries from either SignedByKEK2011 or SignedByKEK2023.
    • Note that it was not possible to use symlinks, as the GitHub API does not resolve symlinks URLs (the download URL it provides is the one of the symlink text), and also, because some workflows depend on being able to read the date from the commit that modifies the target of the symlink, whereas the GitHub API only ever returns the date the symlink was created.
    • However, we also additionally create a SignedByKEKLatest symlink, that currently points to SignedByKEK2023, so that workflows that want to anticipate KEK 2023 expiration in 11 years years can start using that symlinked reference as a semi-immutable means of accessing the latest DBX binaries.
    • Addresses #463.

    Impact

    • Impacts functionality? → No. It restores functionality that was lost post 92b433e.
    • Impacts security? → No. The files being restored are the same as the ones that existed prior to 92b433e and we encourage Microsoft to validate that the SHA-256 of each of the 4 file that was restored is the same as the one from the files from https://github.com/microsoft/secureboot_objects/tree/02bed0f7e6f94645a52336e70972fc17276a25ad: 
      $ sha256sum PostSignedObjects/DBX/*/*.bin
2089e3125e611376cb44326b5765674255443b2484f88de97251939d18055f68 *PostSignedObjects/DBX/amd64/DBXUpdate.bin
84adfda4e9fe145f06154186760c92545b308f02bbc8231d52ef2b8061abae2f *PostSignedObjects/DBX/arm/DBXUpdate.bin
ec68522271e9ac6c936c8731ce0d74417f8ed39296e85ab0e5801af195459214 *PostSignedObjects/DBX/arm64/DBXUpdate.bin
28c9c939f8fc7eee848b105947b5e1645ec6fd4a59537b93a37f6324f116d4c7 *PostSignedObjects/DBX/x86/DBXUpdate.bin
    • Breaking change? → No. It restores existing functionality.
    • Includes tests? → No. Outside of validating that the content being restored is the same as what was removed, no tests are needed.
    • Includes documentation? Yes. A README.md was added in the restored directory to flag its obsolescence and planned removal for a later date, to give time to worfklow that depend on these files to update.

    Note that, because they are flagged as obsolete, the restored DBXUpdate.bin files do NOT need to be updated, even if the SignedByKEK2011 or SignedByKEK2023 .auth2 files are.

    How This Was Tested

    Validated that the previous GitHub API URLs for the files that were removed were restored and served content.

    Integration Instructions

    N/A

      </blockquote>
  <hr>
</details>
  • scripts: Add incremental mode to get\_auth\_var\_signing\_certificate.py Doug Flick (@Flickdm) (#470)
    Change Details
     

    Description

    Modify the get_auth_var_signing_certificate.py script to support two modes for updating kek_update_map.json:

    1. Incremental Mode (default):

      • Loads existing kek_update_map.json
      • Processes only NEW .bin files not already in the map
      • Preserves existing entry order
      • Minimal diffs when adding new KEK updates

    2. Sort Mode (--sort flag):

      • Processes all .bin files
      • Sorts entries alphabetically by KEKUpdate path
      • Useful for one-time cleanup of main branch

    Changes:

    • process_directory() now accepts sort_output parameter (default: False)
    • Added --sort/-s flag to CLI argument parser
    • Incremental mode loads and merges with existing map
    • Existing entries are skipped when already present (by SHA1 hash key)

    Benefits:

    • Easier code review of KEK update contributions
    • Maintains alphabetical ordering expectations
    • Backward compatible (default behavior is incremental)

    For details on how to complete these options and their meaning refer to CONTRIBUTING.md.

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

    How This Was Tested

    Locally with Test CAs

    Integration Instructions

    N/A



  • [Secure Boot KEK Update] weibu PK-Signed KEK Update liujianhua2008 (#465)
    Change Details
      ## OEM Certificate Submission

    OEM Name: [Weibu]
    Contact Email: [kevin_zhu@weibu.com]

    Certificate Details

    • Platform Key Thumbprint: [815c44daf9858f0f7971cd2d557791e509c55eb4]
    • Expiration Date: [2100-12-31]

    Testing Completed

    • [ √] Windows validation
    • Linux validation

    Security Review

    • [√ ] No known security issues

    Additional Notes

    Platform Key Thumbprint SHA1:815c44daf9858f0f7971cd2d557791e509c55eb4



Full Changelog: v1.7.0...v1.7.1

Contributors

pbatard, Flickdm, and 4 other contributors
Assets 12
Loading