TianoCore EDK II Explained: How Open Source UEFI Firmware Is Built

TianoCore is the open source community behind EDK II, the reference implementation of the UEFI and UEFI Platform Initialization (PI) specifications. Much PC, server and VM firmware starts from EDK II code, which chip makers, BIOS vendors and device makers then extend, sign and ship. Fixes pass through each of them before reaching you.

This guide goes one level deeper than our posts on how the motherboard evolved from BIOS to UEFI, TPM and the BMC and coreboot. We read the EDK II repository itself (its ReadMe, .gitmodules, package tree, release list and published GitHub security advisories), the OvmfPkg README, the edk2-platforms README, the TianoCore wiki pages on building OVMF, SecurityPkg, release planning and security reporting, the TianoCore project site, NIST SP 800-147 and SP 800-193, and the QEMU and U-Boot documentation. Every package name, build flag, date and command below comes from those sources. Where something depends on your board or your hypervisor, we say so.

Key takeaways

• TianoCore began as Intel's "Foundation Code" for EFI, project code name Tiano, which Intel announced it would open source in June 2004. It evolved into EDK and then EDK II, which is maintained today on GitHub as tianocore/edk2.
• EDK II implements two specification families from the UEFI Forum: UEFI (the interface the operating system sees) and PI (how firmware is built internally, in phases called SEC, PEI, DXE, BDS and runtime).
• The repository is split into packages. MdePkg holds the specification definitions, MdeModulePkg the generic core drivers, SecurityPkg Secure Boot, TPM and authenticated variables, CryptoPkg the cryptography wrappers over a bundled OpenSSL or Mbed TLS, and OvmfPkg the firmware for virtual machines.
• Shipping firmware is layered: EDK II core, plus silicon initialization code (often binary), plus an independent BIOS vendor tree, plus the device maker's own changes and signing keys. Each layer pins its own copy of the code, which is why a firmware SBOM is hard to produce and harder to trust.
• OVMF is EDK II built for QEMU, KVM, Xen, Cloud Hypervisor and bhyve. It also carries the AMD SEV and Intel TDX builds used for confidential virtual machines, so a large share of cloud and lab VMs boot EDK II code.
• The project tags a stable release every quarter (February, May, August, November). Security reports go through private GitHub security advisories reviewed by an Infosec group, and TianoCore is a CVE Numbering Authority.
• A fix in EDK II is only the first hop. The project's own archived process notes that boot firmware is rarely updated by consumers or IT departments. NIST SP 800-147 and SP 800-193 describe what a safe, authenticated update and recovery path looks like.

What are TianoCore and EDK II, and where did they come from?

The TianoCore project site tells the origin story plainly. In June 2004, Intel announced that it would release the "Foundation Code" of its Extensible Firmware Interface (EFI) under an open source license. EFI was Intel's successor to the 16 bit x86 PC BIOS. The Foundation Code had been developed inside Intel under the code name Tiano, and Intel described it as its preferred implementation of EFI. That code evolved into the EFI Development Kit (EDK), then into EDK II and a set of related open source projects that now sit under the TianoCore community.

Two things happened to the specification and the code separately, and the split still matters:

1. The specification moved to an industry forum. Intel contributed the EFI specifications to what became the Unified EFI (UEFI) Forum, where they became the original UEFI specifications. The TianoCore site notes that the UEFI Forum does not endorse any particular implementation.
2. The code stayed open source. TianoCore describes EDK II as "a modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications." It is designed to implement those specifications, but it is a codebase, not the standard.

That distinction is the first thing to get right when you talk about firmware. "UEFI" is a set of interface specifications. "EDK II" is one open source implementation of them, and the one most commercial firmware starts from. Other implementations of the UEFI interface exist, including U-Boot's UEFI subsystem, which we compare later.

The two specifications EDK II implements

The operating system only ever sees the UEFI side. The PI side is how a vendor assembles firmware out of modules from different suppliers that agree on file formats and hand off structures.

Licensing and what lives inside the repository

The EDK II ReadMe states that most of the project uses the BSD-2-Clause Plus Patent License. A few components carry additional licenses, including the LZMA compression code in BaseTools and MdeModulePkg, a small file in CryptoPkg, and OvmfPkg, which has its own License.txt. The ReadMe also lists content pulled in as git submodules from other upstream projects, each under its own license. In the current .gitmodules file those are:

So EDK II is itself an aggregate of open source projects pinned at specific commits. That fact drives most of the supply chain discussion later in this post.

What are the PI boot phases, and which packages implement them?

The PI specification divides a firmware boot into phases. Each phase runs with more of the machine available than the one before it, and each hands a description of what it found to the next. Here is the flow on a typical x86 machine, with the EDK II packages where the code lives.

Three details make this flow matter for security:

• HOBs are input. Every later phase trusts data handed up from earlier ones. EDK II advisory GHSA-ch4w-v7m3-g8wx (CVE-2022-36765, published 9 January 2024, filed against UefiPayloadPkg) concerned an integer overflow in CreateHob() that could lead to out of bounds reads and writes of HOB data. The lesson is that boundaries inside firmware are trust boundaries too.
• DXE is where network and storage parsing lives. Anything that parses data from a disk, a USB device or the network before the OS starts is attack surface. In January 2024 the project published GHSA-hc6x-cw6p-gj7h covering nine vulnerabilities in the NetworkPkg IP stack, fixed in edk2-stable202402.
• Management Mode is the crown jewel. On x86, SMM can write the flash and the protected variable store. The OvmfPkg README explains that SMM is used to separate the runtime guest OS from the variable store, precisely so that the guest cannot tamper with Secure Boot state. Advisory GHSA-vx5v-4gg6-6qxr (CVE-2025-3770, published 7 August 2025, fixed in edk2-stable202508) was a privilege escalation into SMM caused by enabling machine check exceptions before the SMM handler was installed.

The core packages, one by one

The EDK II repository today contains these top level packages. Knowing what each one is for helps when you read an advisory or a vendor's firmware release notes.

How does a vendor turn EDK II into shipping firmware?

Nobody ships tianocore/edk2 as is to a physical laptop. EDK II provides the core and a few reference platforms. Real firmware is a stack of several codebases owned by different organisations, and the stack looks broadly like this:

The edk2-platforms README makes the open part of this concrete. Platform description files sit under Platform/{Vendor}/{Platform}, and many platforms "require additional image processing beyond the EDK2 build," which each platform must document in its own Readme. The README also points to edk2-non-osi for binaries needed by some platforms, and requires that platforms build against the current EDK II default branch. That is how open boards work. Commercial firmware follows the same shape but with layers 4 to 6 held privately.

Why that layering makes firmware SBOMs hard

A software bill of materials needs names, versions and suppliers. Firmware breaks all three:

• Forked cores with no upstream version. An IBV tree is EDK II at some point in time, plus backports and private changes. There is no single EDK II tag to report. Two laptops from the same year can carry different snapshots of the same core module.
• Pinned copies of third party libraries. EDK II pins OpenSSL, Mbed TLS, Brotli, Oniguruma, Jansson and the others by git commit. The ReadMe links the OpenSSL license at a specific commit hash rather than a release number. A downstream vendor may update that submodule, may not, or may replace it.
• Binary layers with little metadata. FSP, microcode, security processor firmware, option ROMs on add in cards and vendor DXE drivers arrive as binaries. Their internal composition is rarely published.
• Build time choices change the product. The same source tree builds very different firmware depending on -D flags. OVMF alone changes behaviour with SECURE_BOOT_ENABLE, SMM_REQUIRE and STANDALONE_MM_ENABLE, and a physical platform has hundreds of build time configuration values (PCDs).
• Modules are identified by GUID, not by package name. Firmware volumes store files by GUID. Tools that unpack an image can list modules, but mapping a GUID back to a source commit needs the vendor's build records.

None of this makes a firmware SBOM pointless. It means the useful SBOM comes from the build, written by whoever runs the build, listing the EDK II commit, each submodule commit, each binary blob with its hash and version, and the build flags. A list reverse engineered from a shipped image is a much weaker document.

What is OVMF, and why is it the firmware inside so many virtual machines?

OVMF, the Open Virtual Machine Firmware, is EDK II built for virtual machines. The TianoCore wiki describes it as an EDK II based project "to enable UEFI support for Virtual Machines," with sample UEFI firmware for QEMU and KVM. Its source lives in OvmfPkg inside the main EDK II repository, and its README lists what it supports: the X64 architecture (optionally with IA32 SEC and PEI), QEMU 1.7.1 or later, video, keyboard, IDE, CD-ROM and serial, the UEFI shell, optional network cards, and UEFI Linux and Windows guests.

Why does it show up nearly everywhere? Because a hypervisor that wants to boot UEFI guests needs UEFI firmware, and OVMF is the open source one with years of hypervisor specific work already done. A look at the current OvmfPkg tree shows how wide that work goes:

Arm virtual machines use the sibling ArmVirtPkg, which the EDK II CI builds for AARCH64 on every change.

Why confidential VMs care so much about OVMF

In a confidential VM, the guest's memory is encrypted and the guest does not trust the host. The firmware is the first code inside that boundary, so it becomes part of what the hardware measures and what a remote party checks before trusting the VM. Both major x86 confidential computing designs use OVMF builds for this:

• AMD SEV. QEMU's documentation on AMD memory encryption explains that boot images are encrypted with a fresh key at launch, and the platform produces a launch measurement used for attestation. For SEV-SNP, it gives the measured value as a SHA-256 over the entire firmware flash file (it names OVMF.fd as the example), kernel hashes when they are used, and the vCPU save areas. It also warns that you "must build a stateless firmware file which doesn't use an NVRAM store," because the NVRAM area is not measured. The OvmfPkg/AmdSev/AmdSevX64.dsc build exists for that stateless case and includes a verifier for kernel hashes and a secret injection driver.
• Intel TDX. The OvmfPkg/IntelTdx README describes TDX Virtual Firmware (TDVF) as "an EDK II based project to enable UEFI support for TDX based Virtual Machines." It offers two configurations: basic TDX support merged into the normal OvmfPkgX64.dsc, where the host is still inside the trust boundary, and a standalone IntelTdxX64.dsc with full TDVF features. QEMU's TDX documentation adds that TDVF must be copied into guest private memory and measured before the TD boots, that it cannot be mapped as pflash for that reason, and that QEMU loads it with -bios OVMF.fd.

Practically, the exact OVMF build (its commit, its flags, its embedded certificates) becomes part of what an attestation verifier expects. A cloud provider that rebuilds OVMF changes the expected measurement, which is why reproducible firmware builds and published reference values matter so much in this setting. It is also a place where the SBOM point above is not academic: if you cannot say which commit and which OpenSSL your confidential VM firmware was built from, you cannot say whether a new advisory applies to it.

Secure Boot in OVMF is opt in, and keys are not included

The OvmfPkg README is unusually direct about three facts that trip people up:

1. Secure Boot is a build option. OVMF must be built with -D SECURE_BOOT_ENABLE to support it.
2. No keys ship by default. OVMF comes with no Secure Boot keys installed. You install them through the Secure Boot Configuration screen in the firmware setup UI, or with the OvmfPkg/EnrollDefaultKeys application, which reads the platform key and first key exchange key from an SMBIOS Type 11 OEM string that the hypervisor provides.
3. The variable store has to be protected. Because Secure Boot keys live in UEFI variables, the README warns that anyone able to write directly to the flash variable store can bypass Secure Boot. The fix is to make the key store read only or isolate flash access in SMM, which is why the recommended QEMU flags pair -D SMM_REQUIRE with -global driver=cfi.pflash01,property=secure,value=on.

That third point is an example of a broader rule: Secure Boot is only as strong as the protection on the variables that hold its keys. The README also notes that with -D SMM_REQUIRE, OVMF checks that QEMU actually provides SMM and fails with an assertion if not, even in RELEASE builds, because a security feature must not silently fall back to an insecure mode. Direct kernel boot deserves its own warning. QEMU can start a guest with -kernel and -initrd instead of a disk image, and its documentation adds a -shim option for the case where the UEFI firmware has Secure Boot enabled, so the firmware loads and verifies shim first and shim verifies the kernel. EDK II advisory GHSA-6pp6-cm5h-86g5 (CVE-2025-2296) described how, in older OVMF, a kernel that failed Secure Boot verification in direct boot mode could still be started through a fallback loader. The fix is in edk2-stable202505. If you rely on Secure Boot inside VMs that use direct kernel boot, make sure your OVMF package is built from that tag or later, or from a tree with the fix backported.

Distribution packages usually ship separate builds with and without these options, often named with suffixes such as secboot or 4M, so check which file your VM definition points at.

How does EDK II handle security?

Security in EDK II spans four areas: how vulnerabilities are reported and disclosed, the bundled cryptography, Secure Boot and measured boot, and the capsule update path that delivers fixes.

The security policy and advisory process

The current process is documented on the TianoCore wiki page "How to report a Security Issue." Key points, in the project's own terms:

• Reports go in as a private EDK II GitHub security advisory. Issues in edk2-platforms go to that repository's advisories instead.
• An Infosec group evaluates each report. If it is not a security issue, it becomes a normal issue. If it is, Infosec assesses priority, severity and impact, and discussion, fixes and patches happen inside the private advisory. A public disclosure date is set, and on that date the advisory is published.
• Reports that include a proof of concept and a proposed patch get priority. The page says Infosec "may decide to reduce the Severity of the report to Low" if no proof of concept is included, and that raw output from automated tools is not sufficient on its own. It also asks reporters to analyse AI generated results before submitting.
• Reporters are told never to send security details by email.
• TianoCore is a CVE Numbering Authority. The page says CVEs must be issued for TianoCore content, and may be issued for downstream derivatives, open or closed.

Note one gap a careful reader will spot. The GitHub "Security policy" tab for tianocore/edk2 showed "No security policy detected" when we checked on 24 October 2026, because the repository has no SECURITY.md. The policy lives on the wiki instead, and the advisories tab is where the published advisories are listed.

The older, archived "Security Advisory Process" page is still worth reading for one sentence. It explains why the project once modified the usual embargo practice: "BIOS/Boot firmware is rarely updated by consumers or by enterprise IT departments." That page also described a list of trusted downstream users who received early notice so that implementations based on TianoCore code could be fixed and distributed before public notification. The current GitHub advisory flow replaced it, but the observation about slow firmware updates has not aged.

What the advisory list looks like

Here is a sample of published advisories in the tianocore/edk2 repository as listed by the GitHub advisories API on 24 October 2026. It shows which packages tend to carry security fixes and how fixes map to quarterly stable tags.

Read the last column with care. Advisories are filled in by hand, some leave the patched field empty even though a fix was merged, and the publication date is often months after the fix landed (CVE-2025-2296 was published in December 2025 but lists 202505 as patched). Use the advisory to find the fix commit, then check whether your tree contains it.

Two patterns stand out. First, the image loading and measurement code (PeCoffLoaderRelocateImage, HashPeImageByType, Tcg2MeasurePeImage) appears repeatedly, because it parses untrusted binaries before deciding whether to trust them. Second, the network stack keeps coming back, because PXE and HTTP boot parse packets from the network before any operating system security exists. If your machines never network boot, disabling PXE and HTTP boot in firmware setup removes that surface entirely, regardless of which advisory is current. The most recent advisory, published two days before this post, still listed no patched version when we read it, which is exactly the situation where that setting matters.

Cryptography: OpenSSL or Mbed TLS inside CryptoPkg

Firmware needs real cryptography: SHA-256 and SHA-384 for measurements, RSA and ECDSA for verifying Authenticode signatures on UEFI images, PKCS#7 for authenticated variables and capsules, X.509 parsing for certificate databases, and TLS for HTTPS boot. EDK II does not implement these from scratch. CryptoPkg/Library contains:

• BaseCryptLib, the wrapper API the rest of EDK II calls, built over OpenSSL.
• BaseCryptLibMbedTls, the same API built over Mbed TLS.
• OpensslLib and MbedTlsLib, which compile the bundled upstream sources from the git submodules.
• TlsLib, plus Null variants of the libraries for builds that must not contain crypto.
• BaseCryptLibOnProtocolPpi, which lets modules call a single shared crypto driver instead of linking their own copy.

The supply chain consequence is direct. When OpenSSL publishes an advisory, every firmware that bundles an affected OpenSSL commit is potentially affected, but only in the code paths firmware actually uses. Firmware typically does not run a TLS server, but it does parse X.509 certificates and PKCS#7 structures from places an attacker may influence. Whether a given OpenSSL advisory matters for a given firmware is a reachability question that only the firmware's maintainer can answer with confidence, and that is why downstream vendors need to track which OpenSSL commit they actually built.

Secure Boot, authenticated variables and measured boot

SecurityPkg, as the TianoCore wiki describes it, provides four features: TPM support, user identification, Secure Boot and authenticated variables.

• Secure Boot authenticates UEFI images, such as an OS loader or an option ROM, before they run, so that "firmware drivers are loaded only in an owner-authorized fashion." The verification code checks the image's Authenticode signature or hash against the allowed database (db) and the forbidden database (dbx).
• Authenticated variables protect the key hierarchy. The platform key (PK) signs updates to the key exchange keys (KEK), which sign updates to db and dbx. Our post on enrolling your own PK, KEK and db on Linux walks through that hierarchy on physical hardware.
• Measured boot uses the TPM. SecurityPkg's TCG modules measure firmware components, the GPT, boot loaders and configuration into TPM PCRs and keep an event log, giving the OS and remote verifiers a record of what ran.
• Option ROMs on add in cards are UEFI drivers too and pass through the same image verification. Our post on PCI option ROMs and Secure Boot covers that path.

Capsule updates: how fixes are delivered

UEFI defines a capsule as a data structure the OS hands to firmware to be processed, typically across a reset. EDK II implements capsule based system firmware update through the Firmware Management Protocol (FMP), with FmpDevicePkg for device side support and a signed capsule format checked with PKCS#7 before anything is written. The TianoCore wiki has tutorials on capsule based firmware update and on "capsule on disk," where the capsule is staged on the EFI system partition instead of in memory.

In practice, Linux systems receive these capsules through fwupd and the Linux Vendor Firmware Service, which we cover in our post on firmware updates on Linux with fwupd and LVFS. Windows systems receive them through the OS update service. Either way, the capsule is signed by the device maker, not by TianoCore.

How long does a fix take to reach a device?

There is no single answer, because each hop has its own schedule. What we can do is map the hops and their published cadences.

The stable tag schedule comes from the TianoCore release planning page and the GitHub release list. Each development period runs roughly three months, followed by a soft freeze and then a hard freeze about two weeks before the tag. The RFC on the EDK II breaking change and release process confirms stable tags are cut "on a quarterly basis."

The weakest hop is the last. The archived TianoCore security process said it outright, and the NIST guidance below exists largely because of it. For virtual machines the picture is better, because OVMF arrives as a package from your Linux distribution or cloud provider and a VM restart picks up a new build. For physical machines, an end of support model may keep a vulnerable firmware forever.

What NIST SP 800-147 says about protected updates

NIST SP 800-147, "BIOS Protection Guidelines," was published in April 2011. It gives guidelines for preventing unauthorized modification of BIOS firmware on PC client systems, and explicitly includes UEFI firmware in its definition of BIOS. Its core recommendations are:

• An authenticated update mechanism. Updates are digitally signed, and the firmware verifies the signature with a key it holds before writing flash.
• An optional secure local update mechanism, where physical presence authorizes installing an image, for example for recovery.
• Integrity protection, to prevent unintended or malicious modification of the BIOS outside the authenticated update mechanism.
• Non-bypassability. The guidelines require that no mechanism lets the system processor or any other component bypass the authenticated update mechanism.

The document also says the authenticated update mechanism should prevent unauthorized rollback to an earlier firmware version, which matters because an attacker who can reinstall an older, signed but vulnerable firmware has undone your fix without forging a signature.

The document applies to system firmware stored in the system flash and notes that it does not cover option ROMs, UEFI drivers and firmware stored elsewhere in a computer system. In EDK II terms, SP 800-147 maps to signed capsules, a flash write path that only Management Mode or a protected runtime driver controls, and locking flash before the OS runs.

What NIST SP 800-193 adds: protect, detect, recover

NIST SP 800-193, "Platform Firmware Resiliency Guidelines," was published in May 2018. It broadens the scope from the BIOS to the whole platform, which it defines as the fundamental hardware and firmware components needed to boot and operate a system, and organizes guidance around three principles:

1. Protection of firmware and critical data against unauthorized change, building on SP 800-147's authenticated updates.
2. Detection of unauthorized changes when protection fails, for example by verifying firmware against a root of trust at boot.
3. Recovery to a known good state, rapidly and securely, when corruption is detected.

The abstract warns that a successful attack on platform firmware "could render a system inoperable, perhaps permanently, or requiring reprogramming by the original manufacturer." It names original equipment manufacturers and component suppliers as implementers, and says system administrators and security professionals can use it to guide procurement. That last line is the practical one: ask your hardware suppliers how they meet SP 800-193 before you buy, because you cannot add a recovery root of trust afterwards.

Step by step: build OVMF, boot it in QEMU, enrol keys and read the version

This walkthrough builds OVMF from a stable EDK II tag on an Ubuntu or Debian host, boots it in QEMU with Secure Boot support and SMM, enrols test Secure Boot keys inside a throwaway VM, and reads the firmware version from the guest OS. Nothing here touches the firmware of your physical machine. The only files written are inside the build tree and a VM variable store you create.

1. Install the build prerequisites

The OvmfPkg README lists the requirements: a build environment that can build MdeModulePkg, an ASL compiler (on Linux that means iasl) and NASM. The edk2-platforms README adds that the build tools need Python 3 and libuuid, and that you usually have to install uuid-dev yourself.

sudo apt update
sudo apt install -y build-essential git python3 python3-venv uuid-dev iasl nasm \
  qemu-system-x86 ovmf openssl

2. Clone EDK II at a stable tag, with submodules

Pick the latest stable tag rather than the moving default branch. The submodules matter: without them, CryptoPkg has no OpenSSL to build and the build fails.

git clone https://github.com/tianocore/edk2.git
cd edk2
git checkout edk2-stable202608
git submodule update --init --recursive
git submodule status    # record these commits; they are your crypto and compression versions

Save the git submodule status output. It is the beginning of an honest SBOM for the firmware you are about to build: the EDK II tag plus the exact OpenSSL, Mbed TLS, Brotli and other commits.

3. Build BaseTools and set up the environment

make -C BaseTools
. edksetup.sh

edksetup.sh sets WORKSPACE and creates Conf/target.txt and Conf/tools_def.txt from templates if they do not exist.

4. Build OVMF with Secure Boot and SMM

You can edit Conf/target.txt as the TianoCore wiki shows (set ACTIVE_PLATFORM, TARGET_ARCH and TOOL_CHAIN_TAG) or pass the same values on the command line:

build -a X64 -t GCC -b RELEASE \
  -p OvmfPkg/OvmfPkgX64.dsc \
  -D SECURE_BOOT_ENABLE=TRUE \
  -D SMM_REQUIRE=TRUE

Older guides, including the TianoCore wiki page above, use the tool chain tag GCC5. The tool definitions template in edk2-stable202608 records that GCC5 was deprecated in favour of GCC and later removed, so use GCC on current tags and GCC5 only if you deliberately build an old tag. The OvmfPkg README says the output lands under $WORKSPACE/Build/*/*/FV, and OvmfPkgX64.dsc sets its output directory to Build/OvmfX64, so for this build:

ls Build/OvmfX64/RELEASE_GCC/FV/
# OVMF.fd  OVMF_CODE.fd  OVMF_VARS.fd  ...
sha256sum Build/OvmfX64/RELEASE_GCC/FV/OVMF_CODE.fd

OVMF_CODE.fd is the firmware code and should be mounted read only. OVMF_VARS.fd is a template variable store; every VM gets its own copy. Record the SHA-256 of OVMF_CODE.fd next to your submodule list.

5. Boot it in QEMU with protected flash

Make a per VM copy of the variable store, then start QEMU with the SMM flags from the OvmfPkg README. Q35 is the only machine type supported for SMM.

cp Build/OvmfX64/RELEASE_GCC/FV/OVMF_VARS.fd ./testvm_VARS.fd
qemu-img create -f qcow2 testvm.qcow2 20G

qemu-system-x86_64 \
  -machine q35,smm=on,accel=kvm \
  -m 4096 -smp 2 \
  -global driver=cfi.pflash01,property=secure,value=on \
  -drive if=pflash,format=raw,unit=0,file=Build/OvmfX64/RELEASE_GCC/FV/OVMF_CODE.fd,readonly=on \
  -drive if=pflash,format=raw,unit=1,file=./testvm_VARS.fd \
  -global ICH9-LPC.disable_s3=1 \
  -drive file=testvm.qcow2,if=virtio \
  -cdrom ./your-linux-installer.iso \
  -debugcon file:ovmf-debug.log -global isa-debugcon.iobase=0x402

The -debugcon options come from the README and capture firmware debug messages, which the README says go to I/O port 0x402 by default. RELEASE builds suppress debug messages, so use a DEBUG build (-b DEBUG) if you want a detailed log. The README also explains why -pflash style drives are required for Secure Boot builds: only emulated flash gives full UEFI variable support. Using -bios instead means variables are only partially emulated and may be lost on reboot.

If you have no ISO handy, the firmware drops to the built in UEFI Shell when it finds no bootable media, which is enough to explore.

6. Enrol test Secure Boot keys inside the VM

Do this only in a test VM. Enrolling a platform key changes who controls the VM's Secure Boot policy. On a physical machine, enrolling the wrong keys or clearing the defaults can stop the operating system, GPU option ROMs or other signed components from loading. If you adapt any of this for hardware, follow our physical machine guide, back up the existing variables first, and confirm you are working on the intended machine.

Generate a self signed test certificate for the platform key and first KEK on the host:

openssl req -new -x509 -newkey rsa:2048 -nodes -days 365 -sha256 \
  -subj "/CN=Test PK and KEK for OVMF lab/" \
  -keyout PkKek1.key -out PkKek1.pem

Turn it into the SMBIOS Type 11 OEM string format the OvmfPkg README specifies (the GUID prefix tells EnrollDefaultKeys which string to read):

sed \
  -e 's/^-----BEGIN CERTIFICATE-----$/4e32566d-8e9e-4f52-81d3-5bb9715f9727:/' \
  -e '/^-----END CERTIFICATE-----$/d' \
  PkKek1.pem | tr -d '\n' > PkKek1.oemstr

Add this to the QEMU command line (QEMU 5.2 or later can read the string from a file):

  -smbios type=11,path=PkKek1.oemstr

Then make the enrolment tool reachable from the VM. The build places EnrollDefaultKeys.efi in the build output directory; copy it to a small FAT image or a USB image you attach, boot to the UEFI Shell, change to that file system (for example fs0:) and run EnrollDefaultKeys.efi. The README says the application enrols the PK and first KEK from the OEM string. Its source in edk2-stable202608 goes further: it also enrols the widely used commercial operating system vendor certificates compiled into it (the original ones and the 2023 generation) into KEK and db, and a single placeholder hash into dbx. That makes it convenient for booting mainstream signed installers, and it is also exactly why you should read the source of the version you build before relying on it. Alternatively, open the firmware setup menu, go to the Secure Boot Configuration screen, switch to custom mode, and enrol the PK, KEK and db entries by hand from files on attached media.

Reset the VM. From a Linux guest you can confirm the state:

mokutil --sb-state
# SecureBoot enabled

If your test Linux installer is signed with keys you did not enrol in db, it will now refuse to boot. That is Secure Boot doing its job, and the reason a test VM is the right place to learn this.

7. Read the firmware version from the operating system

Firmware identity is exposed through SMBIOS Type 0 (BIOS Information), which Linux reads into sysfs:

cat /sys/class/dmi/id/bios_vendor
cat /sys/class/dmi/id/bios_version
cat /sys/class/dmi/id/bios_date
sudo dmidecode -t bios

On a physical machine these show the device maker's or IBV's version string, not an EDK II tag. On an OVMF guest the values depend on how the firmware and hypervisor were configured. On Windows, use PowerShell:

Get-CimInstance -ClassName Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate
Confirm-SecureBootUEFI

For machines managed by fwupd, fwupdmgr get-devices lists the system firmware with its current version and GUIDs, and fwupdmgr get-updates shows whether a newer signed capsule is available. To map a version back to source, you need the vendor's release notes; most do not publish the EDK II tag they built from.

How do EDK II, coreboot, U-Boot UEFI and closed firmware compare?

The U-Boot documentation is candid about the design choice: "A full blown UEFI implementation would contradict the U-Boot design principle 'keep it small'." That is a reasonable trade on an embedded board, and it is the main reason EDK II remains the default where full UEFI behaviour is needed.

Two clarifications. "Open source" in the first three columns still often includes binary silicon blobs on physical hardware; our coreboot post covers which ones. And "closed" firmware is not a separate codebase from EDK II in most cases; it is EDK II core plus private layers, which is why EDK II advisories are relevant to closed firmware even when you cannot see the code.

Common mistakes

• Treating "UEFI" and "EDK II" as the same thing. UEFI is the specification. EDK II is one implementation. An advisory in EDK II affects vendors who built from the affected code, not every UEFI system.
• Assuming a stable tag fix reaches your laptop. The tag is hop three of eight. Check your device maker's firmware advisories, not just TianoCore's.
• Booting Secure Boot OVMF with -bios. The OvmfPkg README says Secure Boot builds need -pflash style drives, because -bios only partially emulates variables and they may be lost.
• Sharing one OVMF_VARS.fd across VMs. Each VM needs its own copy of the variable store. Sharing one means sharing Secure Boot keys and boot entries, and concurrent writes can corrupt it.
• Enabling Secure Boot without protecting the variable store. The README warns that writing directly to the flash variable store bypasses Secure Boot. Use SMM_REQUIRE and the secure pflash flag, or an equivalent isolation.
• Expecting OVMF to have keys by default. It does not. A Secure Boot capable OVMF with no PK enrolled is in setup mode and will boot unsigned images.
• Leaving network boot enabled where nobody uses it. The NetworkPkg stack has a history of advisories. Turn off PXE and HTTP boot in firmware setup on machines that boot from local disk.
• Building from the default branch and calling it a release. Use a stable tag, record the submodule commits, and keep the build log. Otherwise you cannot later answer "were we affected?"

FAQ

Is TianoCore the same as UEFI?

No. UEFI is a set of specifications published by the UEFI Forum. TianoCore is the open source community that maintains EDK II, an implementation of the UEFI and PI specifications. The TianoCore site notes that the UEFI Forum does not endorse any particular implementation.

Who created EDK II?

It grew out of Intel's EFI "Foundation Code," developed under the code name Tiano. Intel announced in June 2004 that it would release that code under an open source license, and it evolved into EDK and then EDK II. Today it is developed in the open on GitHub with maintainers from many companies, listed per package in Maintainers.txt.

What is OVMF used for?

OVMF is EDK II built as firmware for virtual machines. It lets QEMU, KVM, Xen, Cloud Hypervisor and bhyve guests boot in UEFI mode, with optional Secure Boot, SMM and TPM support, and it has builds for AMD SEV and Intel TDX confidential VMs.

Does my laptop run EDK II?

Probably parts of it. Most commercial PC firmware is built by an independent BIOS vendor or the device maker on top of EDK II core code, plus silicon vendor code and proprietary modules. You usually cannot tell which EDK II version from the OS, because the BIOS version string belongs to the device maker.

How often does EDK II release?

Quarterly. Stable tags are named by year and month, for example edk2-stable202608, published on 21 August 2026. The next, edk2-stable202611, is planned for 20 November 2026.

How do I report a vulnerability in EDK II?

Open a private security advisory on the tianocore/edk2 GitHub repository (or on edk2-platforms for platform code). Include a proof of concept and a proposed patch if you can. Do not send details by email. TianoCore is a CNA and issues CVEs for its own code.

Does EDK II use OpenSSL?

Yes, by default. CryptoPkg wraps a bundled OpenSSL, included as a git submodule, behind its BaseCryptLib API. Mbed TLS is available as an alternative backend through BaseCryptLibMbedTls.

How do I check my firmware version on Linux?

Run cat /sys/class/dmi/id/bios_version and cat /sys/class/dmi/id/bios_date, or sudo dmidecode -t bios for the full SMBIOS record. If fwupd is installed, fwupdmgr get-devices shows the system firmware version and whether updates are available.

Where Safeguard fits

Safeguard does not scan firmware images, unpack firmware volumes, or verify Secure Boot or TPM measurements, and it does not generate hardware or firmware bills of materials. The fit is with the software around firmware. An EDK II build is a git repository with pinned open source submodules, Python build tools, CI pipelines, container images that hold the cross compilers, and the scripts your team writes to sign capsules and roll them out. Those are ordinary source repositories and container images, and Safeguard can scan them with safeguard scan --dir ., --image <name> or --sbom <file> if you already produce an SBOM from your build records.

Firmware projects are assembled from open source parts like any other software: the crypto library, the compression code, the build tooling and the containers that run them all pick up CVEs. The fit here is indirect, since the options below cover the code and images you build and ship, not the vendor's silicon blobs or the flash chip itself.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show Safeguard on ordinary software projects, not on firmware images. They apply to the repositories and containers around an EDK II build: the build container with its cross compilers and Python tooling, the CI workflow, and the signing and rollout scripts your team maintains.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same ask, approve and test loop fits a firmware tooling repository where every change to a build or signing script should be reviewed before it runs.

Click through it at your own pace, or open it full screen.

Firmware build and signing hosts are often kept off the general network. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build host can scan the build tree and the containers stored there without sending the tree elsewhere to be built.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about known vulnerabilities in the projects that hold your firmware build tooling, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• TianoCore: What is TianoCore?
• EDK II repository ReadMe (tianocore/edk2)
• EDK II .gitmodules
• EDK II releases (stable tags)
• EDK II published security advisories
• EDK II security policy tab
• OvmfPkg README
• OvmfPkg source tree
• CryptoPkg library tree
• edk2-platforms README
• TianoCore wiki: How to report a Security Issue
• TianoCore wiki: Security Advisory Process (archived)
• TianoCore wiki: EDK II Stable Tag Planning
• TianoCore RFC 0003: EDK II breaking change and release process
• TianoCore wiki: How to Build OVMF
• TianoCore wiki: OVMF
• TianoCore wiki: SecurityPkg
• TianoCore wiki: Capsule based system firmware update
• NIST SP 800-147: BIOS Protection Guidelines
• NIST SP 800-193: Platform Firmware Resiliency Guidelines
• NIST SP 800-147 full text (PDF)
• EDK II tools_def.template at edk2-stable202608
• OvmfPkg EnrollDefaultKeys.c at edk2-stable202608
• OvmfPkg IntelTdx README
• UefiPayloadPkg README
• QEMU documentation: AMD memory encryption
• QEMU documentation: Intel TDX
• QEMU documentation: Direct Linux boot
• U-Boot documentation: UEFI on U-Boot
• U-Boot Licenses README
• coreboot README

Last reviewed: 24 October 2026. EDK II package layout, build tool chain tags, OVMF build options and advisory status change between stable tags; check the repository and advisories for the tag you build.