This is a short post to announce the release of efitools version 1.4. The packages are available here:
http://download.opensuse.org/repositories/home:/jejb1:/UEFI/
Just select your distribution (various versions of Debian, Ubuntu, Fedora and openSUSE).
The main additions over version 1.3 is that there are two new utilities: efi-readvar and efi-updatevar that allow you to read and manipulate the UEFI signatures database from linux userspace. The disadvantage of these tools is that they require the new efivarfs filesystem to be mounted somewhere in the system (efivarfs was added in kernel 3.8, so you either have to be running a very recent distribution, like openSUSE Tumbleweed, or you have to build your own kernels to use it). To mount the efivarfs filesystem, just do
modprobe efivars
mount -o efivarfs none /mnt (or some other useful mount point)
As long as this is successful, you can now use the efi- tools to read and write the secure variables. In order to write the variables in User Mode, you must have the private part of the Platform and Key Exchange Keys available. So, assuming your private part of the platform key is PK.key, you can add your own KEK with
efi-updatevar -a -c KEK.crt -k PK.key KEK
And then add your own signature database key with
efi-updatevar -a -c DB.crt -k KEK.key db
Where KEK.crt and DB.crt are X509 certificates.
Note that by default, files in the efivarfs filesystem are owned by root and have permission 0644, so efi-readvar can be executed by any user, but efi-updatevar needs to be able to write to the variable files (i.e. would have to run as root).
There’s also extensive man pages documenting all the options for both efi-readvar and efi-updatevar.
What’s the status of a signed PreLoader.efi that works on older UEFI systems? Your current one only works with UEFI 2.3.1 (does not matter if secure boot is enabled or not). It does not work with UEFI 2.0.
I was actually waiting for you to confirm the 1.3.6 update works on non secure boot platforms. After that it will be about two weeks to get it through the Microsoft signing process … so does it work?
Latest arch linux isos (built against your latest efitools tree) seems to finally boot just fine on my UEFI 2.1 asus laptop I had sent you dmpstore a year ago.
Unfortunately there doesn’t seem to be any newer signed binary since 2013.
Could you get MS to sign last git?
Thanks.
Ok, now i tested the PreLoadere.efi from the Debian 6 amd64 package and it started without error with my UEFI 2.00 system. It would be nice when you could call the HashTool.efi on startup if you hold down a specific key. I would prefer a modifier but i guess UEFI does not support that, so maybe backspace or whatever. A grub 2.00 patch with a similar fallback like for gummiboot would be cool too. There is no easy way to start the HashTool.efi once grub is loaded, maybe with a custom grub.cfg, will check that next week. Also it would be nice when you could add an option to install not only a hash but also a key like shim – not via the key tool – thats one step too much. shim 0.2 looks really ugly and i did no see a new shim version with improved gui and combined features.
OK, I pushed into the git repo a patch that will start HashTool if the H key is held down during boot. It will be in 1.4.1 when I get around to releasing that.
You can certainly add HashTool.efi as a gummiboot target. I think it might be possible as a grub targed, but I’d have to check that (grub is used to loading and linking kernel binaries, I’m not sure what it does with pure EFI ones).
There’s not much point allowing HashTool to add a key, because the PreLoader won’t recognise the signature. There’s no cryptographic code in PreLoader (which is why the binary is 1/10 the size of shim).
Well the problem i found while testing uefi fastboot is when it is active with disabled link for usb/ps2 you can not enter anything when the HashTool starts. If you use the expected way to start from usb key or dvd from a system with Win8 preinstalled then fastboot is inactive and you can use your keyboard. But when you do a hd install then usually a grub 2 efi binary is written which is a different binary compared to what is used for starting. When i used that as loader.efi then i could not use the HashTool to enroll the hash and you can not select another system to boot. Most likely it would start the next os when the HashTool would just exit, or what do you think? Add a 60s fallback timeout and then just quit everying? Would be nice when you would test fastboot this way.
I’m not sure what to say about this. “Fast Boot” isn’t a UEFI spec, so I assume it’s some type of OEM bypass. The problem for me, of course, is that this option isn’t present either in tianocore or in the Tunnel Mountain UEFI system I have. I can guess that if the problem is the keyboard isn’t connected, then an initialisation inside the loader to connect it might be the work around, so I can try that, but you’ll have to test it.
Alternative way would be starting the setup in case it is possible.
I can not say that fastboot is part of UEFI in general. But MS wanted systems to POST in 2s or less – this can be only done when you skip some things. Therefore you now have got the option to go to firmware setup mode or start from other devices directly as Win 8 menu entry on reboot (while holding shift). This was needed as the keyboard it not required work on boot – even if you might see press XX key to enter setup. Basically you don’t need that option to debug this. Just add a timeout and abort anything. In my theory it would automatically start the next bootloader when the first fails. And 2 bootloader entries is something you should be able to test with any implementation.
I am trying to compile 32 bit, but I get some errors even with -m32 added in CFLAGS in Make.rules for ia32 arch. It seems commit 36e847b8 in lib/security_policy.c introduced some asm code which breaks the cross-compiling. I know most people may not take care the 32-bit UEFI, but just hope to get some clues here… Thanks.
… Error: bad register name `%rsp)’
… : Error: bad register name `%rdi’
… : Error: bad register name `%rsi’
… : Error: bad register name `%r10′
… : Error: bad register name `%rsp’
… : Error: bad register name `%rax’
…
The code is only designed to be compiled on x86_64 currently. The assembly is to do thunking from the MS ABI to the ELF ABI. In theory, with gcc 4.7 or newer you can use the __attribute((ms_abi)) instead of thunking to achieve this, but that would make the package uncompilable on older distributions.
Any update about a timeout feature and new signed binaries?
I’m having problems hashing binaries that have been signed with a Secure Boot key, such as Fedora kernels. Is there some way to do this? Thanks.
I was imprecise and posted before I’d investigated enough. To elaborate: HashTool.efi seems to register some signed binaries OK, but others return an error that reads “Hash failed (is efi binary valid?): (2) Invalid Parameter”. As an example, it fails on Fedora 18’s vmlinuz-3.9.9-201.fc18.x86-64. Two earlier Fedora 18 kernels are signed OK. It’s also failed on builds of rEFInd and associated EFI driver binaries I’ve created with TianoCore and then signed with my own keys, but not with binaries created with GNU-EFI and signed with my own keys. (I’ve tested a limited number of these binaries, though, so I’m not 100% sure there’s a causal connection here.) (Note that I’m rEFInd’s developer.)
Same issue as Rod. I am using Fedora 20.
When trying to sign I get this:
Hash failed (is efi binary valid?): (2) Invalid Parameter
So for me the tool is absolutley useless the way it is now.
Also I would like to mention that this does not work:
[root@bat mnt]# mount -o efivarfs none /mnt/efivarfs
mount: special device none does not exist
But efivars is already mounted.
[root@bat ~]# mount | grep efi
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
[root@bat ~]# efi-readvar
No efivarfs filesystem is mounted
Something seems to be wrong here.
I found a workaraound to use secure boot with your tool.
Rods comment brought me to the idea to remove the signature.
I put this to /etc/kernel/postinst.d/loader-postinst.sh:
/bin/pesign -r -i ${KERNEL_IMAGE}.sig -o ${KERNEL_IMAGE};
For an unsigned kernel it is still possible to use the HashTool.
Tested with Fedora 20.
Regarding the error message:
“No efivarfs filesystem is mounted”
I perpared a patch which works on my system:
http://www.frank-ansari.de/efi/efitools.patch
Hi jejb, whats missing here (desperate!) is a step by step. your readme on the usb mini iso is not accessible (by me at least – yes i know im stupid) since ist gpt formatted. well anway, peicing it all together has got me to the point where loader.efi can’t be involked by bootx – message is : (2) load failure loader.efi or something to that effect. would you be so Kind to help out. im using a kali Linux 64 bit iso to do a live boot from usb. simply thanks in advance!
Pingback: Gentoo and Windows 8.1 secure boot setup | Benjamin Börngen-Schmidt
Pingback: » Linux: The UEFI & SecureBoot impact, how severe?
Please note that it is NOT sufficient to just mount the efivarfs filesystem in order to make the EFI variables writeable.
Those pseudo files have the immutable attribute set, i.e. you have to first execute:
chattr -i /
I am still only able to write to DB but neither to KEK nor to PK (after having cleared all keys from the UEFI setup).
Also note that if an EFI variable is newly created by an update, it has the immutable attribute SET (which has to be manually cleared first).