Protecting Linux from systemd’s EFI attack

Peter Jones of Red Hat has submitted a patch to the Linux-EFI mailing list, which helps with the recent systemd attack against Linux’s EFI. Patchset email excerpted below:

Preventing “rm -rf /sys/firmware/efi/efivars/” from damage

Here’s a patchset to make all the variables in efivarfs that aren’t well known to be reasonably safe to delete be immutable by default. This should alleviate the danger of somebody accidentally using “rm” to remove some proprietary file that turns out to be important to the platform, which for some reason it also can’t regenerate during POST. In all cases this is just preventing the user from accidentally triggering a major security problem with their underlying firmware, but stopping accidents isn’t a bad thing.  These firmwares still need CVEs and updates to fix them.  Maybe using ESRT and fwupd 🙂

For more information, see the linux-efi mailing list archives.


Dell info on Linux firmware updates

Regarding the new firmware update service available for Linux OEMs:

There is a new article from Dell on this topic:

(Published on behalf of Mario Limonciello, OS Architect of Dell Client Solutions Group’s Linux Engineering team.)

I’m happy to announce that starting with the Dell Edge Gateway 5000 we will be introducing support to natively flash UEFI firmware under Linux.  To achieve this we’re supporting the standards based UEFI capsule functionality from UEFI version 2.5.  Furthermore, the entire tool chain used to do this is open source. Red Hat has developed the tools that enable this functionality: fwupd, fwupdate, & ESRT support in the Linux kernel.  For the past year we have been working closely with Red Hat, Intel, & Canonical to jointly fix hundreds of issues related to the architecture, tools, process, and metadata on real hardware.  Dell will be publishing BIOS updates to the Red Hat created Linux Vendor Firmware Service (LVFS).  Red Hat provides LVFS as a central OS agnostic repository for OEMs to distribute firmware to all Linux customers. […]

Dell — along with Red Hat, apparently — are setting a great example, I hope other OEMs do as well with Linux. 🙂 It makes me think Dell is working to deal with this recent comment of William (of Dell):

Red Hat creates Certificates-Shipped project

Nice, Kiur Seifried of Red Hat has a new project listing the certs/keys the use. I wish all vendors did this.

——– Forwarded Message ——–
Subject:     [oss-security] Announcing
Date:     Tue, 24 Nov 2015 21:38:35 -0700
From:     Kurt Seifried <>
To:     oss-security <>

The idea is to create a comprehensive list of shipped certs/keys/etc by open source vendors/distributions/projects so that:

1) we have a list of secrets maintained by external parties that we rely upon
2) we can audit them and make sure we should be trusting them
3) also spot changes more easily (since the existing corpus is available)

I’m guessing there are some surprises waiting for us.

Kurt Seifried — Red Hat — Product Security — Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact:

securely managing IoT gateways

Russel Doty of  Red Hat has an article in Mil-Embedded entitled “IoT: Embedded and Secure”:

“Last time I wrote about how the Internet of Things (IoT) is impacting the design of military embedded systems; this month, I’d like to address IoT and security. Specifically, I want to address the security processes involved in managing IoT gateways, which are vital to the successful operation of critical applications. […]”

Full article:

tlsfuzzer announced

Hubert Kario of Red Hat announced a new tool on the OSS-security list today. The tool, ‘tlsfuzzer’, is for reproducing, testing and (in the future) automatically finding issues in TLS implementations.

I’m looking forward to seeing if this can help test Tianocore’s HTTPS support, when TLS is added. 🙂

Click to access ruxcon2015-kario-slides.pdf

For more information, see the full post on the OSS-security list.

Laszlo’s OVMF SMM patch status

Laszlo Ersek of Red Hat has a huge patch to Tianocore, which adds SMM to OVMF, and just posted a detailed status update to the EDK2-devel mailing list, The current test results of patch look impressive! Pretend the following table is using a fixed font:

  accel  bits  guest OS         OS boots  efibootmgr works on  S3 resume
  —–  —-  —————  ——–  ——————-  ———
  TCG    32    Fedlet 20141209  pass[1]   BSP and AP           pass
  TCG    64    F21 XFCE LiveCD  pass[1]   BSP and AP           fail[2]
  KVM    32    Fedlet 20141209  pass      BSP and AP           pass
  KVM    64    F21 XFCE LiveCD  pass      BSP and AP           fail[2]
  KVM    64    Windows 8.1      pass      n/a                  fail[2]

I’ve excerpted the key items from the TODO section of the status report: 🙂

– celebrate a bit this weekend (look at that “OS boots” column!)
– celebrate some more?

Full status report (including most of the details, and the omitted footnotes listed above):

(Also note that the EDK2-devel mailing list, which recently moved from to Intel’s, is now hosted on Gmane under the gmane.bios.edk2 namespace. The previous SourceForge list is listed under the gmane.bios.tianocore namespace.)

Red Hat UEFI Secure Boot patch for Linux kernel

Red Hat’s Product Security team is working with OSS-security to get a CVE listed for the below patch. Excerpting the OSS-security request from Wade Mealing of Red Hat, which was in turn paraphrased from Linn Crosetto, perhaps others:

When the kernel was booted with UEFI Secure Boot enabled, securelevel is set. If kexec (either through crash or admin action) is then used to load the same kernel, after reboot securelevel is disabled. In this state, the system is missing the protections provided by securelevel, for example kexec may be used to load an unsigned kernel via the legacy system call kexec_load. In the securelevel patchset, the state of UEFI Secure Boot is queried in the EFI stub, and sets a boot_params flag to indicate the state of UEFI Secure Boot. This flag is then used in setup_arch() to determine the correct state of securelevel. If the kernel is not booted via the EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.

TLDR: this allows a bypass the security mechanism of securelevel/secureboot combination.

This patchset affects Red Hat specific kernels as secureboot is not fully fully implemented upstream yet.

It appears you need an account to view the bug database entry, and the patch:

Firmware Summit results

Al Stone of Red Hat posted a summary of the recent Firmware Summit that took place at the recent Linaro Connect event.

There’s a discussion on the state of ACPI on ARMv8, and Linux support. “So, please tell Linaro if there is something needed from the ACPI spec.  Call, write or send carrier pigeons, just let us know.

There is a discussion on ACPI’s _DSD and Device Properties. A new mailing list has been setup to help. A new repo of information —  on how to submit, approve, and use device properties in a community approved manner:

Matthew Garret wrote a document on Secure Boot:

I omitted a few items from the workshop’s notes. Read the full status here:

Linux firmware update

As pointed out on Phoronix, there’s a new blog post by Peter Jones of Red Hat on the status of firmware updates on Linux.

Phoronix has been covering this much better than I have:

ACPI testing with BITS Python

Recently, Josh Triplett of Intel gave a talk on using BIOS Interface Test Suite (BITS) at LinuxCon North America.

Demystifying ACPI and EFI via Python and BITS

Click to access bits-with-demo.pdf

BTW, Josh also gave this talk at LinuxConNA’15 as well:

Everything’s a File Descriptor

Click to access fd_0.pdf

I think I’ve mentioned BITS in this blog before. But just in case I’ve not, BITS is a powerful, strange set of BIOS diagnostic tools. BITS started as a BIOS-centric tool, but now includes some UEFI support as well. BITS uses the GRUB boot manager as it’s UI, using GRUB menus for different features, see the screenshots page for a better understanding:

BITS also includes a Python interpreter, so you can do interactive Python, or write scripts to test firmware. BITS has interfaces for BIOS, UEFI, and ACPI data.

Jake Edge wrote an excellent follow-up to Josh’s LinuxCON talk, with an article in, discussing BITS’s Python for UEFI and ACPI investigations.

In a talk that could easily be seen as a follow-on to his PyCon 2015 talk, Josh Triplett presented at LinuxCon North America on using Python to explore the low-level firmware of today’s systems. The BIOS Implementation Test Suite (BITS) provides an environment that hearkens back to the days of BASIC, PEEK, and POKE, as he demonstrated at PyCon in Montréal in April, but it is much more than that. In Seattle at LinuxCon, he showed that it can also be used to look at and use the EFI and ACPI code in a system—all from Python.

The article is part of subscriber-only content, and has been ‘leaked’ (see next URL below), and as the link on the page mentions, an occasional leak isn’t too bad, and helps with subscriptions. If you don’t have a LWN subscription, please think about it, they are probably the best news source for low-level Linux technologies. They have a 1-month free trial.

After reading this article, Laszlo Ersek of Red Hat started up a thread with Josh on the QEMU and UEFI dev mailing lists, with some new ways of thinking about using BITS Python for ACPI testing. Lots of good ideas on this thread, if you care about QEMU, ACPI, AML, or ACPICA tools please read the thread: sorry, I’m too lazy to summarize all of the ACPI nuances in the thread, it’s only a few messages.

Using Python to investigate EFI and ACPI
Newsgroups: gmane.comp.emulators.qemu, gmane.comp.bios.edk2.devel

I hope some of the ACPI/AML testing ideas in this thread happen!

More Information:

Linux Security Summit 2015 proceedings available

As part of LinuxCon North America, the Linux Security Summit recently finished, and presentations are now available (I omitted the few talks which had no presentations from below list):

* Keynote: Giant Bags of Mostly Water – Securing your IT Infrastructure by Securing your Team, Konstantin Ryabitsev, Linux Foundation
* CC3: An Identity Attested Linux Security Supervisor Architecture, Greg Wettstein, IDfusion
* SELinux in Android Lollipop and Android M, Stephen Smalley, NSA
* Discussion: Rethinking Audit, Paul Moore, Red Hat
* Assembling Secure OS Images, Elena Reshetova, Intel
* Linux and Mobile Device Encryption, Paul Lawrence, Mike Halcrow, Google
* Discussion: Core Infrastructure Initiative, Emily Ratliff, Linux Foundation
* Security Framework for Constraining Application Privileges, Lukasz Wojciechowski, Samsung
* IMA/EVM: Real Applications for Embedded Networking Systems, Petko Manolov, Konsulko Group, Mark Baushke, Juniper Networks
* Ioctl Command Whitelisting in SELinux, Jeffrey Vander Stoep, Google
* IMA/EVM on Android Device, Dmitry Kasatkin, Huawei Technologies
* Subsystem Update: Smack, Casey Schaufler, Intel
* Subsystem Update: AppArmor, John Johansen, Canonical
* Subsystem Update: Integrity, Mimi Zohar, IBM
* Subsystem Update: SELinux, Paul Moore, Red Hat
* Subsystem Update: Capabilities, Serge Hallyn, Canonical
* Subsystem Update: Seccomp, Kees Cook, Google
* Discussion: LSM Stacking Next Steps, Casey Schaufler, Intel

Linaro Firmware mini-Summit next month

Today on the Linaro Firmware Summit mailing list, Al Stone of Red Hat just announced the next Firmware Summit

What: Linaro Firmware mini-Sumit (at Linaro Connect)
When: Tuesday, September 22th, 2015, 2-6pm
Where: Hyatt Regency San Francisco Airport Hotel, Burlingame, CA

Initial agenda topics include:

1) Current state of ACPI on ARM
2) Support/backing for a longer term organization (i.e., mailing lists, web sites, further meetings…)
3) Use of _DSD device properties
4) Follow-up on others items from the last meeting (mostly promised documents)

Other topics are being solicited. See the full posting on the fw-summit list archives.

Openstack vulnerability with QCOW2 images

Today Tristan Cacqueray of Red Hat — and of the OpenStack Vulnerability Management Team — reported a CVE-backed issue with Glance, and it’s use of QCOW2 (“QEMU Copy On Write”, a QEMU-based image format). Glance is the OpenStack Image Service, which provides discovery, registration, and delivery services for disk and server images, as well as a REST-based API.

Glance v2 API host file disclosure through qcow2 backing file
OSSA 2015-014, CVE-2015-5163

“Eric Harney from Red Hat reported a vulnerability in Glance. By importing a qcow2 image with a malicious backing file, an authenticated user may mislead Glance import task action, resulting in the disclosure of any file on the Glance server for which the Glance process user has access to. Only setups using the Glance V2 API are affected by this flaw. This fix will be included in the future 2015.1.2 (kilo) release.”

For the full announcement, including more URLs to patches, see the openstack-announce or oss-security mailing lists. Look to the CVE link in the future, there’s nothing there yet.

(Openstack aside, I wonder if codebases are vulnerable to an “importing a qcow2 image with a malicious backing file” attack?)


Earlier this month, Laszlo Ersek of Redhat contributed a large patch to the TianoCore project, adding SMM support to OVMF.

“OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure, and in the UEFI variable driver stack. The purpose is (virtual) hardware separation between the runtime guest OS and the firmware (OVMF), with the intent to make Secure Boot actually secure, by preventing the runtime guest OS from tampering with the variable store and S3 areas.”

The changes require QEMU usage with these flags:

qemu-system-i386-machine q35,smm=on,accel=(tcg|kvm)-global driver=cfi.pflash01,property=secure,value=on -smp cpus=1 …

This new OVMF SMM works on the q35 machine, only in uniprocessor guests, and with TCG acceleration it only works on x86 not x64. Apparently the lack of 64-bit support is due to 64-bit code not available in TianoCore(?):

“In addition, using OvmfPkgIa32X64.dsc or OvmfPkgX64.dsc, the patch set even stops building after a point, *if* -D SMM_REQUIRE is passed. This is due to the unavailability of 64-bit open source components from Intel, and the build breakage is fully intentional — it shows that the -D SMM_REQUIRE feature is build-level incomplete for OvmfPkgIa32X64.dsc and OvmfPkgX64.dsc, and marks precisely where further development is needed.”

More Information:

Check out the 58-part patch on the mailing list, the first and last messages have a lot more documentation:

Linux distros (and FreeBSD): join the UEFI Forum

Hey Linux/FreeBSD distros: it’s great that you’ve got UEFI support including Secure Boot certs. But that’s not enough, you need to join the UEFI Forum, and help evolve UEFI to be more Linux-friendly.

Right now, the last time I checked, the only Linux distros that had joined were: Canonical (Ubuntu), Red Hat, and SuSE. As well as Linaro. Excluding SuSE and Redhat’s commercial products, that means that Ubuntu, Fedora, and OpenSUSE are the community Linux distros that may have the best UEFI support.

UEFI Forum members have access to:
* member-only communications (web forums)
* member-only invites to meetings/events (including the 1-3 plugfests they do each year).
* member-only access to software and specs the public doesn’t have.
* access to file bugs/change requests, which the public cannot do.

I think you get access to their non-public trunk, a subset of which is exported to the public as TianoCore, but I’m not sure. (Hypocritically, I’m not a member yet, still working on it, blocking on some new company infrastructure.)

If you join, you can help evolve and improve UEFI, and have early access to UEFI resources so your distros can be ready for any changes. You can attend the plugfests and do interop testing with other UEFI products/projects, to find problems before your users have to see them.

If you don’t join, you’ll be constantly reacting to UEFI Forum releases, have less resources than UEFI Member distros have, and if there’s a problem all you can do is whine and blame Intel and/or Microsoft, when you should look into the mirror instead.

The Linux Foundation should help enable community distros, which don’t have large corporations to back their membership, to get involved as well. The Free Software Foundation should join and participate, instead of keeping their heads in the sand and wish everyone would stop using UEFI. Embrace and Extend.

In addition to Linux distros, FreeBSD also supports UEFI, and is not a UEFI Forum member. iX Systems and FreeBSD Foundation: this also applies to you.

You also need to register your distro with the UEFI Forum’s ESP Subdirectory Registry, so you can have some UEFI binaries (boot loader, etc.) in a well-known location. Ex, if Debian’s cbootstrap gets ported to a UEFI Application, then \EFI\Debian\cbootstrap.efi would be an example of where the file would be stored. Right now, Debian is registered, but not a member of the UEFI Forum!?

Intel, ARM, Linaro, Red Hat, SuSE, and Canonical have been doing a great job improving UEFI so it works better with non-Apple, non-Microsoft operating systems. IMO, more distros need to get involved and help.

More Information:

While I’m on my soapbox, Linux distros should consider some UEFI-centric rescue options in their boot CDs. ALT Linux Rescue ISOs include rEFInd boot manager, and let you optionally jump into UEFI Shell. You could use UEFI-aware GRUB for this, instead of rEFInd. Additionally, it would be nice to also give access to running: FWTS (FirmWare Test Suite), Intel CHIPSEC to test the hardware/firmware for security. It would also be nice to include the UEFI port of CPython 2.7x, along with the UEFI Shell, for more powerful diagnostic abilities. Distro installers should also consider installing UEFI Shell and UEFI Python and CHIPSEC onto system’s ESP, in an advanced mode, not just let them access via install ISO. Of course, there are security issues by enabling extra Pre-OS tools, user would need to opt-into all of this. Intel’s LUV-live, which Linaro is porting to AArch64, contains BITS (BIOS Interface Test Suite), FWTS, CHIPSEC all in one convenient location. I hope other Linux distros emulate some of LUV-live’s diagnostic and rescue abilities.

Secure Boot strength varies by Linux implementation

[UPDATE, with input from readers, see EOM. Thanks!]

UEFI Secure Boot is a build-time feature of UEFI that helps secure the boot process from some boot-time attacks, optionally using TPM hardware if available. Secure Boot became widespread on Windows hardware during Windows 8 timeframe. Windows aside, other operating systems have to support UEFI Secure Boot. Linux supports UEFI and UEFI Secure Boot (as does FreeBSD). Different Linux distributions have different Linux kernels, with different versions, different patchsets, and different build-time directives enabled. So, Fedora’s Linux kernel is different than SuSE’s Linux kernel, etc.

I saw a recent comment from a UEFI security researcher who had been building a Linux liveboot CD and running CHIPSEC — which includes a native Linux kernel driver, and running it on UEFI systems with Secure Boot enabled.

“Ubuntu appears to have shim and do secure boot but not enforce kernel module signing.”

This Ubuntu behaviour was a change in behaviour from the Fedora-based systems the researcher was used to using. I was curious about the difference in distros w/r/t enforcing kernel module signing. So I asked on the FirmWare TestSuite (FWTS) list if there was a test for this. Roderick W. Smith of Canonical — and author of rEFInd boot manager and the definitive Linux boot loader/manager reference on — replied clarifying the situation:

“Yes, that’s correct. Ubuntu’s kernel doesn’t attempt to enforce Secure Boot policy beyond the main kernel file; once the kernel’s loaded, it’s possible to load an unsigned kernel module. Fedora, as you inferred, does require signing of kernel modules. Fedora’s approach is arguably more secure, since an attacker can’t load a malicious kernel module once the system has booted, but leads to problems with third-party kernel modules, like the in-kernel portions of nVidia and ATI/AMD video drivers. FWIW, the decision to do it this way was made before I joined Canonical, so I’m not sure who made the decision.”

Ivan of Canonical replied with more information:

“On Linux, two stage booting has implemented for secureboot. First stage is firmware boot to shim and then shim will take care to check signature and boot with grub and kernel. Booting with/without kernel signed is under shim and grub implementation, Ubuntu provides the singed kernel in official releases, and would like to keep the flexibility for user to build their kernel, so Ubuntu doesn’t block booting when user uses unsigned kernel.”

The security researcher who reported this speculated that Canonical’s policy may be due to them not wanting to put their distro signature (or perhaps worry about license issues in doing so) on some 3rd party (non open) binary.

As I understand things, this is beyond the strict “UEFI Secure Boot” definition, and on to what OS-centric post-UEFI Secure Boot security techniques it will implement. I guess some call it “OS Secure Boot” to differentiate it from “UEFI Secure Boot”, but I don’t see any formal definition for that term.

I wish there was more precise information about Secure Boot implementation from each Linux distro. System administrators and technical support engineers will need to know these nuances, as will security researchers. Pehaps Linux Foundation or UEFI Forum — or some Wikipedian(s) — could help with a comparison of Secure Boot on different OSes? Perhaps FWTS or CHIPSEC could have a test to check? Perhaps the UEFI Forum could note these nuances at their next plugfest, and setup test cases combinining Linux OSVs with a test case that loads dynamically load native OS drivers: perhaps using CHIPSEC as the test case may suffice, it loads a native helper driver.

So, don’t just look at if Secure Boot is enabled or not, look at what Linux OS you’re using, and how it implements Secure Boot. And remember attackers are also making this choice, and looking for your softer Linux targets, so be more careful when using those systems.


Updated information:

The reason this issue came up is that the researcher was using Intel CHIPSEC, which when run on Linux it uses a Linux kernel module. Unlike most drivers, which get loaded when OS initializes, then stay loaded, the CHIPSEC driver behaves differently. The CHIPSEC userland Python app compiles the kernel module, and loads the module when it starts, then unloads the driver when it finishes (because the driver enables risky things, see it’s warning.txt). On Fedora, this kind of CHIPSEC driver loading behavior will not work, with Secure Boot enabled, until you setup moklist and sign the module. By contrast with Fedora, on Ubuntu, CHIPSEC is able to load the unsigned driver without the user having to change anything (convenience). Here’s more information on how Fedora does it’s module signing process:

qboot, new x86 firmware for qemu

Last week, Paolo Bonzini of Red Hat announced qboot, a new x86 firmware option for QEMU. qboot is a minimal x86 firmware that runs on QEMU and, together with a slimmed-down QEMU configuration, boots a virtual machine in 40 milliseconds on an Ivy Bridge Core i7 processor. The code is 8KB in size.

More information:

Linux ACPI support for ARM-v8

Earlier this month, Linaro announced their effort to upstream the Linux patches to enable ACPI on ARMv8. It appears the patch may make it in Linux 4.1, but it is not done yet.

The Linaro blog post credits a large list of people who helped: UEFI Forums’ ACPI Working Group, Linaro, ARM, Red Hat, Huwaei, Qualcomm, AMD, AMD, APM, HP, other Linaro LEG members, and Linux kernel maintainers, including Linus.

As part of this effort, on March 26th, ARM hosted a Firmware Summit focused on ARMv8 and ACPI, with dozens attending, including SoC vendors, BIOS vendors, firmware and kernel developers, ODMs and OEMs.

The Linux kernel checking comment for this patchset includes this description:

‘This series introduces preliminary ACPI 5.1 support to the arm64 kernel using the “hardware reduced” profile. We don’t support any peripherals yet, so it’s fairly limited in scope:
– MEMORY init (UEFI)
– ACPI discovery (RSDP via UEFI)
– CPU init (FADT)
– GIC init (MADT)
– SMP boot (MADT + PSCI)
– ACPI Kconfig options (dependent on EXPERT)
ACPI for arm64 has been in development for a while now and hardware has been available that can boot with either FDT or ACPI tables. This has been made possible by both changes to the ACPI spec to cater for ARM-based machines (known as “hardware-reduced” in ACPI parlance) but also a Linaro-driven effort to get this supported on top of the Linux kernel. This pull request is the result of that work. These changes allow us to initialise the CPUs, interrupt controller, and timers via ACPI tables, with memory information and cmdline coming from EFI. We don’t support a hybrid ACPI/FDT scheme. Of course, there is still plenty of work to do (a serial console would be nice!) but I expect that to happen on a per-driver basis after this core series has been merged.’

Upon accepting the patch, Linus said:

‘No earth-shattering new features come to mind, even if initial support for ACPI on arm64 looks funny. Depending on what you care about, your notion of “big new feature” may differ from mine, of course. There’s a lot of work all over, and some of it might just make a big difference to your use cases.’

This *is* big new feature, if you care about firmware and Linux.
More Information:

Red Hat OVMF whitepaper

[This is not fresh news. Since this is a new blog, I’m starting to work backward on some noteworthy news/releases that happened shortly before the blog started…]

Mid-2014, Red Hat released a whitepaper documenting the UEFI OVMF format. It is well-written, and useful for those new to UEFI, coming from a Linux background. The document is Copyright (C) 2014-2015, Red Hat, Inc., licensed CC BY-SA 4.0.

Abstract: The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is designed to replace the Basic Input/Output System (BIOS) firmware interface. Hardware platform vendors have been increasingly adopting the UEFI Specification to govern their boot firmware developments. OVMF (Open Virtual Machine Firmware), a sub-project of Intel’s EFI Development Kit II (edk2), enables UEFI support for Ia32 and X64 Virtual Machines. This paper reports on the status of the OVMF project, treats features and limitations, gives end-user hints, and examines some areas in-depth.

Keywords: ACPI, boot options, CSM, edk2, firmware, flash, fw_cfg, KVM, memory map, non-volatile variables, OVMF, PCD, QEMU, reset vector, S3, Secure Boot, Smbios, SMM, TianoCore, UEFI, VBE shim, Virtio

Read the whitepaper: