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
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
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 25th, 2005 and subsequently their publication of the first UEFI Specification (v2.00) on January 31st, 2006. The foundation of that original UEFI spec. was Intel's final EFI Specification, v1.10 from December 1st, 2002.
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
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.
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:
ShellBinPkg.zipfile has the full UEFI Shell, as well as a minimal implementation, built for a variety of architectures. Recommended for power users.
<arch>\EFI\OC\Tools\OpenShell.efiin 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.
¹ 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.