efitools 1.4 with linux key manipulation utilities released

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.

21 thoughts on “efitools 1.4 with linux key manipulation utilities released

  1. Kano

    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.

    Reply
    1. jejb Post author

      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?

      Reply
      1. mirh

        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.

        Reply
  2. Kano

    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.

    Reply
    1. jejb Post author

      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).

      Reply
      1. Kano

        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.

        Reply
        1. jejb Post author

          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.

          Reply
  3. Kano

    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.

    Reply
  4. Mega

    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’

    Reply
    1. jejb Post author

      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.

      Reply
  5. Rod Smith

    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.

    Reply
    1. Rod Smith

      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.)

      Reply
  6. fansari

    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.

    Reply
  7. fansari

    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.

    Reply
  8. fansari

    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.

    Reply
  9. Norman

    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!

    Reply
  10. Pingback: Gentoo and Windows 8.1 secure boot setup | Benjamin Börngen-Schmidt

  11. Pingback: » Linux: The UEFI & SecureBoot impact, how severe?

Leave a Reply to Rod Smith Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.