UEFI Plugfest 2025 Topics

[makubacki]

The UEFI 2025 Developers Conference and Plugfest is quickly approaching and will be held from October 7 - 10 at the Google Sunnyvale Campus in Sunnyvale, CA.

For those planning to attend, we’re currently compiling a list of discussion topics for the week. Below is what we have so far. If you have additional topics you’d like to explore, please feel free to leave a comment on this discussion thread. We’ll do our best to allocate rooms and organize focused sessions around as many of them as possible.

---

• Build and Continuous Integration (CI)
  • CI infrastructure to run CI jobs and get results on vendor-specific platforms
  • Staged CI builds to improve PR CI time
  • Standardizing edk2-platform build requirements
  • Adding CI to the edk2-platforms repository
    • Build Tools Update from those in the know: what's on the horizon, what are the ongoing efforts, etc.
    • edk2/BaseTools vs edk2-basetools: what's the process for keeping the two in sync; is there a (long-term) plan to merge the two?
    • Brainstorming of the ways to boost build tools performance
    • Incompatibilities between edk2 build tool and stuart DSC/FDF parsers
• Binary Images
  • PE/COFF section and file alignment requirements
  • Page protection requirements
  • Size requirements
  • Code requirements (e.g. CryptoPkg assembly)
• Community
  • AI tool policy discussions
  • Wiki doc updates
    • Remove stale info
    • Update inaccurate info
• General
  • EFI Byte Code (EBC)
  • PRM for GCC/Clang toolchains
  • Standalone MM supervisor
  • x86 32-bit support
• Security
  • UEFI Secure Boot
    • Feedback
    • FMP embedded driver support
    • UEFI Secure Boot 3rd Party Signing Process
    • Updates
  • Post-Quantum crypto
  • Sharing a crypto binary with a well-defined API
• Tool Chains
  • Clang support
  • Simplifying tool chain config
• UEFI Self-Certification Tests (SCT)
• UEFI Secure Boot
  • Revocations and SBAT

[omdxp]

It would be great if you allocate some time for UEFI network booting.

[makubacki]

Are there any specific aspects of UEFI network booting you'd like to have covered?

[omdxp]

Honestly I'm new to network booting in general, but I'd be happy to listen to any specific topic about it.

[kevindavisinsyde]

Michael, It would be great if these discussions were transcribed or on a teams meeting for those of us that aren’t traveling to the plug fest. Kevin Insyde Software On Oct 1, 2025, at 4:57 PM, Michael Kubacki ***@***.***> wrote:  The UEFI 2025 Developers Conference and Plugfest<https://uefi.org/events/uefi-2025-developers-conference-and-plugfest> is quickly approaching and will be held from October 7 - 10 at the Google Sunnyvale Campus in Sunnyvale, CA. For those planning to attend, we’re currently compiling a list of discussion topics for the week. Below is what we have so far. If you have additional topics you’d like to explore, please feel free to leave a comment on this discussion thread. We’ll do our best to allocate rooms and organize focused sessions around as many of them as possible.

…

________________________________ * Build and Continuous Integration (CI) * CI infrastructure to run CI jobs and get results on vendor-specific platforms * Staged CI builds to improve PR CI time * Standardizing edk2-platform build requirements * Adding CI to the edk2-platforms repository * Binary Images * PE/COFF section and file alignment requirements * Page protection requirements * Size requirements * Code requirements (e.g. CryptoPkg assembly) * Community * AI tool policy discussions * Wiki doc updates * Remove stale info * Update inaccurate info * General * EFI Byte Code (EBC) * PRM for GCC/Clang toolchains * Standalone MM supervisor * x86 32-bit support * Security * UEFI Secure Boot * Feedback * FMP embedded driver support * UEFI Secure Boot 3rd Party Signing Process * Updates * Post-Quantum crypto * Tool Chains * Clang support * Simplifying tool chain config — Reply to this email directly, view it on GitHub<#11573>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIA55TA7EUJNXC25A4GPMML3VQ53TAVCNFSM6AAAAACIBNUSO2VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYHE3TCNBQHE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[makubacki]

Michael, It would be great if these discussions were transcribed or on a teams meeting for those of us that aren’t traveling to the plug fest.

@kevindavisinsyde, thanks for the suggestion, we’ll do our best to take notes and share key takeaways for those who can’t attend in person.

[felixpgithub]

Michael,

I would be interested in a broad build tools discussion. Here are some of the areas of interest:

• Build Tools Update from those in the know: what's on the horizon, what are the ongoing efforts, etc.
• edk2/BaseTools vs edk2-basetools: what's the process for keeping the two in sync; is there a (long-term) plan to merge the two?
• Brainstorming of the ways to boost build tools performance
• Incompatibilities between edk2 build tool and stuart DSC/FDF parsers

[makubacki]

Those are great topics. There should be good a quorum for them. I'm looking forward to your presentation!

[jsetje]

Hi Michael,

If anyone is interested in discussing UEFI Secure Boot revocations via either SBAT or dbx, I'll be on site Thursday and Friday.

I'm particularly interested in creating an easy to understand framework for how to roll them out without breaking any systems in the field. I'm happy to lead a discussion with a tiny number of slides if that's helpful.

[makubacki]

Sounds good @jsetje. @Flickdm and @SochiOgbuanya will be good contacts to speak with.

[edhay]

Hi @makubacki
We are working on analysis and development of new tests in UEFI-SCT to cover the test gaps with the latest UEFI specification v2.11.
I am interested in discussing edk2 code gaps which are needed for the new UEFI-SCT test development.

[makubacki]

@ardbiesheuvel has booked a conference room today from 3:30pm - 5:30pm to start discussing some of these topics. Ard will need to escort those interested in attending to the room. If you are interested, we'll gather around 3:30pm in the conference catering area. Space will be somewhat limited due to the room size, but we'll try to accommodate as many people as possible.

[kevindavisinsyde]

Insyde’s Tim Lewis is very invested in these topics. He is in the UEFI area. Greatly appreciate if someone can lead him to the meeting.

[makubacki]

Notes From 10/8/2025 Meeting

• Build and Continuous Integration (CI) (discussed)
  • Need CI infrastructure to run CI jobs and get results on vendor-specific platforms (discussed)
    • Agreed that this is useful after getting basic build and CI in place in edk2-platforms. Some present volunteered to make hardware available.
  • Staged CI builds to improve PR CI time (discussed)
    • Note: Use the PR Eval tool as much as possible to reduce time
    • Note: Building on Linux is faster, prioritize Linux builds in earlier stages
      • Clang tends to find more issues than MSVC so prioritize that earlier too
    • Note: Initially we can balance the load between GitHub workflow and Azure pipeline agents by bringing Linux first to GitHub workflows (running in the container)
      • Can use a GitHub action to kick off Azure pipelines for Windows builds
  • Standardizing edk2-platform build requirements (discussed)
    • This is considered the first step to making platforms in edk2-platforms easier to build and add CI on top of
  • Adding CI to the edk2-platforms repository (discussed)
    • Build Tools Update from those in the know: what's on the horizon, what are the ongoing efforts, etc. (discussed)
      • Build tools topics covered in other build points.
    • edk2/BaseTools vs edk2-basetools: what's the process for keeping the two coordinated; is there a (long-term) plan to merge the two? (discussed)
      • A first pass needs to be made to clean up stale platforms
      • Resource were lost working on this work. No active work on it at the moment. Available for others to pick up if they have capacity to do so.
        • General consensus is that we'd like to move to Python based basetools.
    • Brainstorming of the ways to boost build tools performance (did not discuss in detail)
      • Note: Take advantage of Python 3.13 threading improvements to improve performance
    • Note: There is an opportunity to simplify some of the build file grammar (might be breaking but overall beneficial)
      • Simplify to reduce parsing complexity and platform integration complexity
    • Note: Some Python 2 code is still around. We can clean it up.
    • Note: Need tests for all basetools refactoring work to show how behavior is maintained/impacted.
    • Incompatibilities between edk2 build tool and stuart DSC/FDF parsers (discussed)
      • Agreed that parsers need to improve to be more consistent. Three main points need to be checked so that they are in sync: (1) build specifications, (2) existing tools, and (3) new tools
    • Note: edk2-platforms stable tag will trail edk2 by a few weeks
      • Vendor testing for the stable tag should start at soft freeze
      • Start getting feedback at that point
      • Add critical bug fixes and breaking changes to stable tag releases notes
      • Add a checkbox in the PR template if a fix is a critical bug fix to the last stable tag
• Binary Images (not discussed)
  • PE/COFF section and file alignment requirements
  • Page protection requirements
  • Size requirements
  • Code requirements (e.g. CryptoPkg assembly)
• Community
  • AI tool policy discussions (discussed)
    • Contributors are expected to sign-off on their changes following the DCO
    • A policy will not be created to explicitly forbid AI. But all contributors must understand the changes that they are submitting. If they cannot, pull requests will be closed.
    • No issue with contributions of an AI instruction file submission to the project
  • Wiki doc updates (discussed)
    • Need to remove stale info and update inaccurate information
    • Idea is to move away from the GitHub wiki and instead host all of the wiki content in a dedicated repository where pull requests can be accepted
    • We need to encourage more regular updates to wiki and in-tree code documentation
• General
  • EFI Byte Code (EBC) (discussed)
    • Questions raised in the discussion:
      • Whether to bring back EBC? No conclusion in the meeting.
      • Only support 64-bit?
      • How will EBC signing work? UEFI CA signing is not available right now.
      • Whether to ship multiple native architecture images instead of a single EBC OP ROM?
    • Challenges
      • Debuggability is difficult
      • The original EBC compiler team is not available
    • Comes down to three options in the end:
      • EBC for 64-bit only
      • Multiple native images
      • Build for a single architecture and others use an emulator
    • Conclusion: Keep the EBC code in the tree. The correct audience is not present for the discussion. Revisit with add-in card owners in the future.
  • PRM for GCC/Clang toolchains (not discussed)
  • Standalone MM supervisor (not discussed)
  • x86 32-bit support (not discussed)
• Security (not discussed)
  • UEFI Secure Boot
    • Feedback
    • FMP embedded driver support
    • Revocations and SBAT
    • UEFI Secure Boot 3rd Party Signing Process
    • Updates
  • Post-Quantum crypto
  • Sharing a crypto binary with a well-defined API
• Tool Chains (not discussed)
  • Clang support
  • Simplifying tool chain config
• UEFI Self-Certification Tests (SCT) (discussed)
  • We should add a SCT label to issues and PRs so SCT related content can easily be filtered
  • Note: You can file a top-level issue and attach sub issues
  • We should tag which UEFI version the issue is related to (2.8, 2.9, etc)
  • We need to define a way to ensure tests are more regularly updated as UEFI spec releases are made

---

The group thought a monthly call to discuss topics like these would be useful.

[makubacki]

Notes From 10/10/2025 Meeting

• Security
  • UEFI Secure Boot
    • Embedded drivers will not be supported by default
    • A PCD will allow drivers to be enabled (support disabled by default)
      • If an embedded driver is encountered, a message should be printed that states embedded drivers are not supported
    • Need backward compatibility for EDK II crypto protocol updates
  • Sharing a crypto binary with a well-defined API
    • Tianocore can produce a single crypto binary in the open
    • Next steps: New repo, focus on size, and GitHub release with symbols and binary
      • Need to support source debug and document how to debug the binary with source
    • Start with edk2 RFC for code changes
    • Consider introducing a shared binary during the transition to PQC
      • Probably need PQC code to start showing up in edk2 around 2026.
• PRM for GCC/Clang toolchains
  • Mike's PR is a solution for non-VS toolchains - Add GCC/CLANG Support to PrmPkg #11576
• Tool Chains
  • Simplifying tool chain config
    • Ideas:
      • Defaults per toolchain with override
      • Inheritance and includes
    • There is an opportunity for checking for unused defines in tools_def.txt and DSC files
    • Need further work on how to simplify build rules and allow overriding and consistency
• x86 32-bit support
  • In the 202511 stable tag, announce the plan to remove 32-bit DXE and SMM support after the 202602 stable tag

---

Other Notes

• @makubacki will file a GitHub issue and report effort required to move docs from GitBook to mdBook

[makubacki]

Tacking issue for the wiki migration is: #11619

[bexcran]

Has there been any progress on the edk2-platforms CI since the plugfest?
I'm interested because I have several of the machines that are supported by edk2-platforms, and have set up a Gitlab CI system at https://ci.openfw.io (currently for my personal use) to run CI for the Ampere platforms. I haven't seen any further messages about CI though since the on-site meetings.