UEFI Shell binary images, generated from EDK2 stable
This repository contains pre-built UEFI Shell binary images, generated from official EDK2 stable releases.
These images are provided in the form of a bootable ISO, in order to make them easy to use with boot media creators such as Rufus.
However, these can also readily used by:
Once you have done that, and provided that your machine is set to boot from removable media (and runs a UEFI firmware that uses one of the architectures supported 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, as Microsoft does not allow an external UEFI Shell to be signed for Secure Boot.
These binaries are built in a fully transparent manner, in order to provide you with complete assurance that they do not contain anything malicious.
To validate this claim, you can perform the following:
build
to access the build log, and then look at the Checkout repository and submodules
task. The last line for that task provides the
SHA-1 of the repository commit that was used for the build process (for 21H1
that would be 19803c2b2183849fc3a4d6f08cc3c0549232df0c
).https://github.com/pbatard/UEFI-Shell/commit/
to
validate that you end up with one of the public commits that were
pushed to this repository. This validates that the build was not triggered
by a "hidden" commit, that would perform something malicious, and that we
would later delete, since it is impossible for anyone without an army of
supercomputers to alter a git commit in order to "fake" a specific SHA-1.Browse Files
button on the page you got from the URL that was constructed above and
the click on the edk2 @ #####
link that you see in the repository tree.
For instance, for 21H1, that link will be labelled edk2 @ e1999b2
..yml
from the commit that was used to trigger the build
to also validate that it is not doing anything suspiscious (such as
discarding the built executables to replace them with pre-built malicious
ones downloaded from a third-party server). Again, because you have already
validated, with 100% certainty, that all the steps that are used for the
build 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 plainly
in the .yml
..efi
files, or are
working directly with a .iso
, you can find the relevant SHA-256 displayed
either under the Display SHA-256
step or the Generate ISO images
step
within the build log (and you should of course have validated that the
GitHub Actions' .yml
that was used as part of the build was indeed set
to 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 to
trick someone looking only at the log into thinking that a malicious file
published under Releases, and that was not generated from the automated
build process, did come from the build process)..efi
or
.iso
you downloaded, and verify that they are the same.If you accomplish all the steps above, then you will have established, with
absolute certainty, that the binaries that are being published on our
Releases page can be trusted not to contain malware (that is, provided you do
accept that toolchains like gcc
or GitHub employees can be trusted not to
insert malware on their own, but this is outside of the scope of the kind of
assurance that we can provide here).
And the nice thing is that, because any failure of validation for the points we describe above is very easy to detect, you can rest assured that, even if you do not go through these steps yourself, someone else is likely to, and is bound to say something if we ever are to do anything that looks contrary to our claim that the UEFI Shell binaries published here are 100% trustworthy.