-blue.svg?style=flat-square){kind=icon}
This repository contains pre-built UEFI Shell binary images, generated fromofficial EDK2 stable releases.
UsageThese images are provided in the form of a bootable ISO, in order to make themeasy to use with boot media creators such as Rufus.
However, these can also readily used by:
Partitioning and formatting a media, such as a USB Flash drive, using a FATfile system.Extracting the ISO content as is, onto the FAT partition.Once you have done that, and provided that your machine is set to boot fromremovable media (and runs a UEFI firmware that uses one of the architecturessupported by the release), it should automatically boot into the UEFI Shell.
Note that Secure Boot must be disabled for a UEFI Shell media to boot, asMicrosoft does not allow an external UEFI Shell to be signed for Secure Boot.
Binary validationThese binaries are built in a fully transparent manner, in order to provideyou with complete assurance that they do not contain anything malicious.
To validate this claim, you can perform the following:
Locate the build action for the ISO you downloaded underhttps://github.com/pbatard/UEFI-Shell/actions. For instance, for the 21H1release, this would be https://github.com/pbatard/UEFI-Shell/actions/runs/1160237413.Click on build to access the build log, and then look at the Checkout repository and submodules task. The last line for that task provides theSHA-1 of the repository commit that was used for the build process (for 21H1that would be 19803c2b2183849fc3a4d6f08cc3c0549232df0c).Append that SHA-1 to https://github.com/pbatard/UEFI-Shell/commit/ tovalidate that you end up with one of the public commits that werepushed to this repository. This validates that the build was not triggeredby a "hidden" commit, that would perform something malicious, and that wewould later delete, since it is impossible for anyone without an army ofsupercomputers to alter a git commit in order to "fake" a specific SHA-1.NB: You don't have to take our word for that last claim. Just google "SHA-1collision" and also look into the measures that git is taking to switch toSHA-256 so as to make the possibility of collision impossible.At this stage, you have assurance that the commit that was used to buildthe binary is a public one. However, you must also further validate thatthe EDK2 source that was used for the build is also the public one thatis published from https://github.com/tianocore/edk2, and not some privatepotentially malicious copy. To accomplish that, click the Browse Filesbutton on the page you got from the URL that was constructed above andthe click on the edk2 @ ##### link that you see in the repository tree.For instance, for 21H1, that link will be labelled edk2 @ e1999b2.Validate that this link takes you to a public commit fromhttps://github.com/tianocore/edk2. Once you have done that, then you havevalidated that, not only the build cannot have been triggered by a hiddencommit but also that the EDK2 source for the UEFI Shell that is producedby the build cannot have come from anywhere else but the public EDK2repository.If you are familiar enough with the build process, you should now look atthe GitHub actions .yml from the commit that was used to trigger the buildto also validate that it is not doing anything suspiscious (such asdiscarding the built executables to replace them with pre-built maliciousones downloaded from a third-party server). Again, because you have alreadyvalidated, with 100% certainty, that all the steps that are used for thebuild can only have come from a public commit which everyone has access to,it would simply be impossible for any such behaviour not to appear plainlyin the .yml.At this stage, you should have total confidence that the build process didproduce binaries that can be trusted to have been built only from thepublic unmodified EDK2 UEFI Shell source. Therefore, the one last item tocheck is to validate that the binaries proposed under this project's Releasepage are the actual binaries that were produced from the build, ratherthan some malicious replacements (since the owner of any GitHub project hasthe ability to delete and replace release files). This last step is veryeasy to accomplish however: As part of the build process, we make sure toalso display the SHA-256 for all of the UEFI binaries as well as for theISO images being generated.Thus, depending on whether you extracted individual .efi files, or areworking directly with a .iso, you can find the relevant SHA-256 displayedeither under the Display SHA-256 step or the Generate ISO images stepwithin the build log (and you should of course have validated that theGitHub Actions' .yml that was used as part of the build was indeed setto perform an actual computation of the SHA-256 from the generated files,as opposed to mimicking the display of an SHA-256 computation in order totrick someone looking only at the log into thinking that a malicious filepublished under Releases, and that was not generated from the automatedbuild process, did come from the build process).Compare the SHA-256 from the build log with the one from the .efi or.iso you downloaded, and verify that they are the same.If you accomplish all the steps above, then you will have established, withabsolute certainty, that the binaries that are being published on ourReleases page can be trusted not to contain malware (that is, provided you doaccept that toolchains like gcc or GitHub employees can be trusted not toinsert malware on their own, but this is outside of the scope of the kind ofassurance that we can provide here).
And the nice thing is that, because any failure of validation for the points wedescribe above is very easy to detect, you can rest assured that, even ifyou do not go through these steps yourself, someone else is likely to, and isbound to say something if we ever are to do anything that looks contrary toour claim that the UEFI Shell binaries published here are 100% trustworthy.