How check EFI revision?

Question

How can I check the (U)EFI revision (or specification version) of my laptop

NB: I don't mean the EFI/BIOS version provided by the manufacturer of the laptop/motherboard

Answer 1

Preface

I see (and appreciate!) that you were attempting to be as precise as possible about the language you used in your question, especially since the UEFI¹ Specifications and those which preceded them for EFI² are, by their nature, both intricate and somewhat confusing.

To dispel as much confusion as possible, I'll begin by calling attention to the events and documents which mark the boundary between the original EFI platform (developed and promoted by Intel alone, and whose version numbers all begin with '1') and its successor, UEFI, which is the work of a larger group of stakeholders along with Intel and that's organized as the UEFI Forum (and whose work is distinguished by version numbers that begin with '2'). Those are the formal creation of the UEFI Forum on July 25^th, 2005 and subsequently their publication of the first UEFI Specification (v2.00) on January 31^st, 2006. The foundation of that original UEFI spec. was Intel's final EFI Specification, v1.10 from December 1^st, 2002.

Answer

To arrive at the definitive "according to Hoyle" information you seek about the specific version of your device's UEFI firmware, the ideal venue requires booting it into a UEFI shell, then simply issuing the ver command with the -terse option. This conveniently outputs the unambiguous UEFI version of the firmware, excluding all the other contextual elements produced by using the ver command alone which can be confusing. Here's an example from one of my devices of the output that always precedes the initial command prompt, along with what to expect when invoking the ver -terse command:

  UEFI Interactive Shell v2.0
  Build 8192. Copyright 2008 by Intel(R) Corporation.
  UEFI v2.10 Firmware (Phoenix Technologies Ltd., 0x01014318)

Shell> ver -terse
  2.10

Likewise, you could learn the version of the shell binary instead by using the ver command with the -s option (which implies -terse as well), as the two are distinct and the shell version need not match nor even be equal to or greater than that of the firmware it runs on. Backwards compatibility exists for many earlier shells to run on later firmwares, albeit with a subset of the available functions, and the caveat that earlier shells from the EFI era rarely execute successfully on UEFI devices.³

Shell> ver -s
  2.00

You might have noticed that both values were part of the shell's initialization output, and in fact that's by design, with UEFI shells automatically printing the full, "verbose" output of the ver command whenever they're started. It's overwhelmingly likely that you won't need to issue any commands at all, but boot into the shell, read that output, and reboot to go make use of it. The inaugural UEFI Shell Specification v2.0 introduced this rubric for the layout of the information output by the ver command, and it remains unchanged as of this writing over 15 years later:

UEFI <support-level> Shell v%uefishellversion%
<shell-supplier-specific-data>
UEFI v%uefiversion% (<fw-vendor>, 0x<fw-vendor-ver as 32b hex value> <opt. add'l. info>)

As you can see, the shell version should be the last datum on the first line, and the firmware version should be the second datum on the third and final line printed before the first shell prompt is shown. Also, the variable names in the above rubric are standardized, read-only environment variables present in any UEFI instance, and can be referenced just like you would in most any other shell, too. This would be another way to retrieve the version info, and could even be the underpinnings for a script that you set to automatically run at boot time as a means to bypass the need for a UEFI shell entirely:

fs0:\> echo %uefiversion%
  2.10

fs0:\> echo %uefishellversion%
  2.00

Sourcing a bootable UEFI Shell

I could stop there, but in light of how rarely vendors provide easy access to a UEFI shell in most widely-available systems, let's review the basics of creating a bootable storage medium containing the UEFI shell. You would then use it by selecting said storage device from the One-Time Boot Menu most firmwares make available for a few seconds after the system is first powered on (usually accessed by pressed one of the high-numbered Function keys during those few seconds, such as F10, F11 or F12, though I've also seen it mapped to Esc and even F2 occasionally).

Of course you could partition and format the device that will hold the shell binary manually if you wish, but for those that would prefer a software utility to handle that part I have a few suggestions.

• balenaEtcher (Windows, Linux and MacOS)
• UNetbootin (Windows, Linux and MacOS)
• Rufus (Windows only)
• Ventoy (Windows or Linux)
• Fedora Media Writer (Windows release, MacOS release)
  • Linux release available in most distribution packages repositories such as Fedora, Arch and Flatpak.

Once you have a tool installed and an empty or erasable storage device ready, you'll need a copy of the UEFI Shell for them to work with. A few options for that are:

• UEFI Shell ISO images
  • The developer of the Rufus utility produces very reliable ISO images with the UEFI Shell for the most common architectures all in a single ISO that's ready to flash or burn with any of the above tool. This is the easiest source to use, recommended for all.
• TianoCore EDK2 stable releases
  • This is the official open source project where most generic UEFI firmware development occurs, and they periodically tag stable releases with pre-built binaries. The ShellBinPkg.zip file has the full UEFI Shell, as well as a minimal implementation, built for a variety of architectures. Recommended for power users.
• OpenCore bootloader
  • This is an open-source bootloader that includes the UEFI Shell along with an assortment of other utilities for interacting with various firmwares. It can be found at <arch>\EFI\OC\Tools\OpenShell.efi in the downloadable release archives.

Depending on whether you're working with an ISO or a bare .efi binary executable, you'll either provide the ISO to the utility software as the intended contents for the storage medium or use the utility to create an empty bootable device and then copy the .efi file to the EFI folder it makes in the filesystem of the device's EFI System Partition. Finally, with the bootable medium connected to the system, trigger a reboot and enter the One-Time Boot Menu, select the device with the shell on it and you should be delivered directly to the shell, complete with command prompt, and ready to get the answer to your question.

---

Glossary and Footnotes

¹ Unified Extensible Firmware Interface

² Extensible Firmware Interface

³ A note about backwards compatibility: This is mentioned specifically because it is often necessary to source a UEFI shell executable from third parties, as many manufacturers do not include one in their firmware packages or on their support web sites, or if they do, then make it difficult to expose for download and use. In the event you find yourself needing to do so, you can focus your search for a shell to boot into primarily on locating one from a trustworthy source and much less so on finding one that precisely matches the vintage/expected version of your firmware. In fact, for all the example outputs shown above you can see that (purposely) a rather old shell (compiled in 2008, just after the final revision to UEFI v2.00 was published) was being run on a vastly newer device manufactured c. 2022 with UEFI v2.10 firmware. While I have provided links near the end of my answer to several sources for shells that I deem trustworthy and are available at the time of writing, it should not be assumed that they will remain available nor than my understanding of the subject matter carries over to matters of security; I highly encourage readers to perform their own due diligence in instances like these.