As I said in the previous post, Prometheus came with Win8, which means it has UEFI with SecureBoot enabled by default. It means it will refuse to boot anything it doesn’t trust, like a linux installation liveCD/liveUSB.
Why SecureBoot is not evil
Many people would just shout “SecureBoot is evil, just turn it off ASAP” or something. I disagree.
SecureBoot is meant to allow booting only trusted things. And this is actually a good thing. It can (hopefully) prevent bootkits and evil maids from succesfully attacking you.
The problem is what it treats as trusted. You can change that by replacing the SecureBoot keys, which I will do one day. I don’t feel like doing it right now, so I’ll just use Linux Foundation’s PreLoader. It’s an EFI executable that allows the user to interactively decide what executables he/she trusts, in addition to ones already trusted by UEFI. Linux Foundation went through the process of getting the PreLoader signed by Microsoft, which allows it to run on any Win8 SecureBoot PC.
Booting with PreLoader
PreLoader is actually part of
efitools contains many useful EFI executables, two of which got signed by Microsoft:
HashTool is used by
PreLoader to interactively ask you to put a hash of an executable in the
PreLoader allows booting executables whose hash is in the
MokList even if SecureBoot wouldn’t normally allow it.
I downloaded the MS-signed
HashTool, and grabbed the source of
efitools from git in case I need any of the other tools. I thought
KeyTool may be useful in the future (for replacing the MS keys in UEFI), so I built it. There are also some linux executables in
efitools, I needed one of them:
HashTool, etc. often need to calculate hashes of EFI executables. But they don’t use a regular SHA256 of the whole file. They use SHA256, but skip some parts of the executable (notably the digital signatures area, so that they don’t go in circles because hash needs to include signature which needs to include hash which…). The
hash-to-efi-sig-list program can be used to hash any EFI file this way, and display the hash.
So I took an relatively empty, FAT partitioned USB stick, made an
/EFI/BOOT directory on it, and put the
HashTool.efi on it, and
PreLoader.efi renamed to
bootx64.efi (which is what UEFI expects when looking for a bootloader). PreLoader will try to execute
loader.efi (and start
HashTool if neither SecureBoot nor MokList trust
loader.efi), so I need to put some executable with that name next to
PreLoader. I decided to use
KeyTool for that purpose, because it has an ‘Execute Binary’ menu option with a file picker dialog, which will allow me to choose anything I want to run.
I plugged the USB stick to Prometheus, powered it up, pressed F10 so that the boot selection menu shows up, and chose the USB stick.
PreLoader failed to start
loader.efi, so it launched
HashTool. I chose
HashTool, it showed me its hash and asked if I really want to add it to
MokList. I hashed a copy of
KeyTool.efi on my other PC with
hash-to-efi-sig-list, made sure the two hashes match, and chose chose ‘Yes’.
hash-to-efi-sig-list also saves the hash in some EFI format in a file provided as the second argument. If you just want to see the hexadecimal value of the hash, and don’t need the file, do something like
./hash-to-efi-sig-list SomeFile.efi /dev/null.
Now I can execute any EFI executable I want, whith SecureBoot enabled, by enrolling its hash with
HashTool and executing it with
KeyTool’s ‘Execute Binary’ dialog. Yay!
Wrong hash WTF?!?!!?!
I had problem with some binaries - the
HashTool would show a completely different hash than
hash-to-efi-sig-list. Was I under attack?
efitools before v1.5.2 had a bug in its EFI executable hashing routines, which would produce incorrect hashes if the binary wasn’t aligned to 4096 byte blocks, or something like that. The
HashTool.efi signed by MS are from one of those old versions with the bug - they produce and expect incorrectly calculated hashes. Now when I was to compile the source, I checked out git tag of latest release, which was v1.5.3, so the
hash-to-efi-sig-list used the fixed version of the hashing procedure. No surprise the hashes were different. So I checked out v1.5.1 (latest that still has the bug) in a separate working directory, built
hash-to-efi-sig-list from it, and used it to calculate the hash. It matched with the one from
HashTool, and everything worked ok.
ArchLinux happens to be my distro of choice, so as soon as I downloaded, verified and burned the latest Arch installation ISO, I tried booting Prometheus from it. The live DVD has
HashTool included, but it uses gummiboot as bootloader, so not only the
loader.efi’s hash needs to be enrolled in
HashTool, but also hashes of anything gumiboot launches, including Linux kernel image, and - in case you want to use it - EFI shell.
In my case, for some reason, HashTool only saw the /EFI directory of the Archiso live DVD and its subdirectories. I thought this was gonna be an issue, because on Archiso the kernels are in the /arch/boot directory, but fortunately, gummiboot copies them to the /EFI directory prior to executing… or something… I don’t know how it exactly happens on a read-only medium, but that’s what it looked like, IIRC. Oh, and some (maybe all) of these binaries on the live DVD trigger that hashing bug above.
Anyway, it works, Archiso is able to boot with SecureBoot enabled!