Debunking EFI myths

I’m somehow hoping, although I won’t trust it that much, that this is going to be the last post in the trilogy of myths in need of debunking — the previous two posts involved ccache and x32 and both of them has been quite the controversy. Unfortunately, seeing how much some news sites decided to mangle my words on the topic, I expect this to happen again.

So here it is a list of myths that I heard, especially in relation of my recent posts on the topic.

I didn’t write about Secure Boot. I actually linked to a video from Jo Shields of Debian fame. If you wish, you can pair that with Greg’s video on the same subject. Looks like people need to see computers booting to actually know it is possible. Stupid times we’re in.

I didn’t say that it’s impossible to boot with UEFI! Some (pretend) news site decided to use my post – that explained how to solve the chicken-and-egg problem with needing EFI variables support to set up GRUB 2 to boot off EFI – was actually saying that it’s impossible to boot Linux on UEFI systems.

The only thing in my post that referred to the inability to boot was regarding the default install that Sabayon had: the DVD boots off as BIOS legacy, but there is no way to boot off the harddrive that way.This is not unexpected as, at that point, Sabayon didn’t support EFI at that point at all — Fabio now got that one fixed, and he also implemented some (naïve maybe, at this point) Secure Boot support.

UEFI is not there just to let you use a mouse. Some people expect that the only thing that UEFI is good to do is to have support for mice and graphical setup interfaces. This is a faulty assumption because I have had BIOS-based software that used graphical interfaces and mice before, and my ZenBook has a “classic” textual interface. Sure the new UEFI system allows for a cleaner way to write such interfaces, as it provides drivers for the video card as well as for the input devices, but that’s far from it.

Basically, UEFI does not make that much of a difference for the final user, even though the new Secure Boot can actually make a much more interesting technology for the end user, as it allows (to some degree, depending on the vendor) to only trust your own key and disallow other operating systems to be booted. If you’re a device manufacturer, this has its own importance, even though is what people refers to as “TiVoization” — it makes it extremely easy to set up a signed EFI stub to be the only one being booted … If you have a server or a desktop that you don’t want other people, even with physical access, to access, you probably want to have your key as the only trusted one. Sure there is some “Trusted GRUB” project that many see as a response to the Secure Boot feature — from Matthew’s comments, I wouldn’t want to go near it (storing the whole kernel into the TPM? Are you kidding me?).

SystemRescueCD does not support UEFI. This was my mistake. Indeed the version of SysRescueCD that I had available was 2.x which did not support UEFI. The new SysRescueCD 3 works perfectly fine. And since they boot an UEFI-capable kernel through UEFI boot, you no longer need to do anything in particular beside using grub2-install, and that will take care of efibootmgr.

By the way, I wouldn’t mind having a KDE-based interface that would let me choose what to boot on the next reboot, akin to what OS X already had for a long time… of course that would mean that I would have to find one for Windows as well — my Dell laptop uses dual boot with an external HDD, as I described before.

14 thoughts on “Debunking EFI myths

  1. Why would you use an EF02 partition at all? It works perfectly fine with an EF00 on the main drive. You only need to get to a live that boots via UEFI (and SysRescueCD 3 fits nicely). Then you just replace the EF02 with an EF00 vfat-partitioned and you’re done.And the grub2 launcher that has to stay in the EFI partition is less than 500k, so the size of said partition can be just a few megabytes and it’ll be fine.


  2. Ah right, I meant EF00, it’s long time since I switched..And yes any live that supports UEFI works, but creating USB drive with only grub2 is faster if you don’t have such live already (maybe there wasn’t any live with UEFI support when I was switching to UEFI).


  3. Ah yes that makes sense now. Yes before there were lives with EFI support, it was quite a mess. As I said in my post I solved it by using the EFI shell and an EFI stub kernel. It would probably have been just as simple to use only the EFI stub and set it as removable boot device. Or to just add the path to it in the setup screen.


  4. I’m pretty sure you don’t need to stick the kernel in the TPM to use trusted grub to secure your system.TPM and secure boot do similar but not quite the same things. Secure boot prevents the system from booting something you don’t trust. The TPM keeps secrets from anything you don’t trust. So, if I secured my system using full disk encryption, the TPM, and trusted grub, then I could stick a live CD in my system and boot it just fine. However, that liveCD could not access anything on my hard drive.In such a scenario the TPM would not store a copy of the kernel, but just a digest of it.If there is some documentation to the contrary, I’d certainly be interested in a link. Thanks.


  5. Sorry, hate to double-post, but Trusted GRUB isn’t really a response to secure boot. It goes back years, back to when MS was pushing Palladium. I wouldn’t consider it a replacement for secure boot – it is just a set of security features.The main use for it would be implementing “passwordless” full disk encryption.


  6. You should check Matthew’s Twitter feed — I suppose he’ll be posting soon about it, knowing the pattern. He posted something about the kernel being transferred into the TPM on the very slow, very small bus, which make no sense. We all expect that the TPM would only store a signature anyway.And in general, I wouldn’t mind a better support for TPM, and getting users out of the idea that TPM == You can’t use your own computer, as it makes sense in so many cases to have a TPM device to store the certificates. I have one on my Dell laptop, and I wish I could use it better. Unfortunately OpenCryptoki is a piece of shit.


  7. SystemRescueCD doesn’t include the grub x86_64-efi files, so you can’t directly grub2-install from there. I needed to install a rootfs on the hard drive with grub2 & install grub from the chroot. Not sure if that’s what you meant or not.Interestingly, on the samsung laptop I installed to last week, I could efi boot from usb. But since I repartitioned the hard disk & wiped windows 8 & the existing efi partition, it no longer detects the usb efi boot in the bios. So I had to burn a CD to continue installing. I have no idea how to get it to detect a bootable usb stick now I guess there’s probably some efibootmgr magic to fix it, but I was mostly just surprised that broke in the first place & wouldn’t mind finding out why.I guess efi bioses & tools still have a way to go to maturity.


  8. Your whole claim about needing EFI vars to setup GRUB2 was factually inaccurate in the first place; you can quite happily feed the requisite arguments to the grub2 setup program (which in my experience is generally little more than the system architecture) – I have in fact done it this way myself in the past since the Gentoo Minimal environment cannot boot from UEFI.Since that time I’ve modified the live env via Catalyst to be capable of booting from a plain old BIOS and UEFI.I even went so far as to provide the requisite patch and files to the releng guys, but I don’t think they’ve bothered/had the time to actually make use of it.


  9. It is not factually inaccurate at all. @efibootmgr@ (which @grub2-install@ calls) *requires* EFI vars to be available. Without that, good luck with booting.The only way to boot without having to set up a boot option with @efibootmgr@ is to use the @bootx64.efi@ file, which is what you do on removable drives, but I would suggest against doing that for a standard bootup as it can freak out some EFI implementations into not booting other removable media at all, if I’m not mistaken.


  10. So, you could use bootx64.efi to start the system, *then* use efibootmgr? (Actually this is what I’m doing for the moment, but I’m running into other issues trying to get grub2 to read lvm-on-raid5).That aside, the whole UEFI thing just feels kinda half baked. The only place it makes sense is to help protect full disk encryption systems – one vulnerable spot is a keylogger inserted into the bootloader/kernel to compromise the encryption key. Secure boot could help prevent this or at least raise the barrier to entry. It’s not a magic bullet, but it could remove a generic attack route – most other attacks I can think of depend on hardware or software specifics.Then again if there’s still a “Clear CMOS” jumper it might not be worth much.


  11. Brad, I’m afraid that you conflate UEFI with Secure Boot, and since I wrote that explicitly, you lose any chance to show you have a clue about this.


  12. Well, either I misunderstood you, or you misunderstood me… or both.I took your original article to infer that there was a chicken & egg problem insofar as you were stating that you cannot setup a UEFI bootloader without first having booted the live media from UEFI.However, the actual case is that you can quite easily boot live media from BIOS mode, prep the system and deploy the requisite GRUB2 UEFI files *without* having EFI vars and then simply reboot, switch the system to use UEFI and continue booting.Granted that without access to the EFIvars you cannot configure the UEFI to auto-boot GRUB2, but having the inconvenience of having to use the UEFI boot manager isn’t really a show-stopper.


  13. I fully admit I don’t have a clue about secure boot – I don’t have any hardware that supports it, and I’m just in the last few days playing around with UEFI at all on my newest motherboard. But instead of just yelling at me (I’m a long time gentoo user and I have a deep admiration for your blog posts), a helpful hint as to why or what I’m not understanding would be appreciated instead. There must be others reading that are confused on this issue.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s