I’m pleased to announce that the Linux Foundation and its Technical Advisory Board have produced a plan to enable the Linux (and indeed all Open Source based distributions) to continue operating as Secure Boot enabled systems roll out. In a nutshell, the Linux Foundation will obtain a Microsoft Key and sign a small pre-bootloader which will, in turn, chain load (without any form of signature check) a predesignated boot loader which will, in turn, boot Linux (or any other operating system). The pre-bootloader will employ a “present user” test to ensure that it cannot be used as a vector for any type of UEFI malware to target secure systems. This pre-bootloader can be used either to boot a CD/DVD installer or LiveCD distribution or even boot an installed operating system in secure mode for any distribution that chooses to use it. The process of obtaining a Microsoft signature will take a while, but once it is complete, the pre-bootloader will be placed on the Linux Foundation website for anyone to download and make use of.
Philosophy Behind this Announcement
The Linux Foundation is committed to giving users freedom of choice on their platforms. Conforming to this stance, we have already published a variety of tools to permit users to take control of their secure boot platforms by replacing the Platform Key and managing (or replacing) the installed Key Exchange Keys here. However, as one of the enablers of the Linux ecosystem, the Foundation recognizes that not everyone is willing (or able) to do this so it was also necessary to find a solution that would enable people to continue to try out Linux and other Open Source Operating Systems in spite of the barriers UEFI Secure boot would place in their way and without requiring that they understand how to take control of their platforms. Therefore, we also formulated a technical plan, which is implemented in this pre-bootloader, to allow distributions to continue functioning in a secure boot environment.
The current pre-bootloader is designed as an enabler only in that, by breaking the security verification chain at the actual bootloader, it provides no security enhancements over booting linux with UEFI secure boot turned off. Its sole purpose is to allow Linux to continue to boot on platforms that come by default with secure boot enabled. The Linux Foundation welcomes efforts by some of the major distributions (e.g. Fedora, SUSE and Ubuntu) to tackle the problem of taking full advantage of UEFI secure boot to enhance platform security and sees the pre-bootloader it is releasing as a stop-gap measure that will give all distributions time to come up with plans that take advantage of UEFI secure boot.
Technical Details
The source code for the pre-bootloader is available in
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
As Loader.c
It is designed to be as small as possible, leaving all the work to the real bootloader. The real bootloader must be installed on the same partition as the pre-bootloader with the known path loader.efi (although the binary may be any bootloader including Grub2). The pre-bootloader will attempt to execute this binary and, if that succeeds, the system will boot normally. If the loader.efi fails to load with a security error (because it is unsigned), the pre-bootloader will stop at a splash screen and ask the user to confirm, by selecting a menu option, that they wish to continue booting loader.efi. If this confirmation (which is the “present user” test) is successful, the pre-bootloader will then execute loader.efi without security verification (if the user denies permission to boot, the pre-bootloader will signal failure and the UEFI boot sequence will continue on to the next boot path, if there is one). To facilitate repeat booting (and to make the pre-bootloader useful for booting hard disks as well as USB keys or DVDs) the pre-bootloader will also check to see if the platform is booting in Setup Mode and if it is, will ask the user for permission to install the signature of loader.efi into the authorized signatures database. If the user gives permission, the signature will be installed and loader.efi will then boot up without any present user tests on all subsequent occasions even after the platform is placed back into secure boot mode. The present user test splash screen that appears in secure boot mode asking for permission to boot loader.efi will also direct the user to a Linux Foundation website where we will gather details of how to place platforms in setup mode and advise the user how to do this, either to install the signature of loader.efi or to take full control of the platform by replacing the Platform and Key Exchange Keys.
We need another loader option. Boots up and if not in setup mode provides option to go to EFI configuration. Remember EFI there is no short cut key to access EFI configuration you need a flag set so next boot it will display configuration options.
Yes the firmware is not in setup mode so we cannot add keys we then need a standard way to get back to change that state. Same with getting back to turn secure boot off if required.
We also need some form of cooperation over the /BOOT/BOOTX64.EFI and other default boot loaders locations. Mostly so that you can take a EFI harddrive out of one machine place in another approve the old boot process and KEK reapply and boot varables reapply.
This is basically the new MBR problem. Linux Foundation working with FreeBSD and others to come to a suitable agreeable solution to all would remove fighting over it.
> We need another loader option. Boots up and if not in setup mode provides option to go to EFI configuration. Remember EFI there is no short cut key to access EFI configuration you need a flag set so next boot it will display configuration options.
We don’t really have a consistent ability to do that from a uefi program, I’m afraid. However, it will be where UEFI ends up if all boot options fail.
> We also need some form of cooperation over the /BOOT/BOOTX64.EFI and other default boot loaders locations. Mostly so that you can take a EFI harddrive out of one machine place in another approve the old boot process and KEK reapply and boot varables reapply.
The spec mandates this, so it’s not alterable. If a distro adopts the LF solution then the pre-bootloader would have to go in /boot/efi//bootx64.efi and the boot loader would then go in /boot/efi/ /loader.efi … that’s about as consistent as it gets.
–We don’t really have a consistent ability to do that from a uefi program, I’m afraid. However, it will be where UEFI ends up if all boot options fail.–
We have already seen buggy EFI implementations. Lets just presume the worst that we have one that no boot works and it plays dead so we have a universal plan for that mess. So basically needs to place a bootloader on drive to get somewhere.
–The spec mandates this, so it’s not alterable. If a distro adopts the LF solution then the pre-bootloader would have to go in /boot/efi//bootx64.efi and the boot loader would then go in /boot/efi//loader.efi … that’s about as consistent as it gets.
Reply–
The issue is the NVRAM varables and KEK. –bootia32.efi, bootia64.efi and bootx64.efi– Kinda work no matter what. After a firmware update the NVRAM and other kinda need settings might go by by same with changing motherboards.
NVRAM can contain the list of bootloaders for the system to attempt in that order.
So if we have like a bootx64.efi that reads from the efi nvram.conf and asks if user wants that configuration restored if there is nvram config or if user wishs to save current configuration.
Then this allows distrobutions to avoid stoping on each other. So you have a suse ubuntu fedora…. If the first boot loader is configuration restore. There is no reason why we could not put in the Linux standard base that the distrobution provided loader that might be the Linux Standard base default goes in EFI sub folder. The nvram.conf information gets updated.
I am not talking about breaking spec. I am talking about taking advantage of the spec that allows you to specifiy bootloader order and where the boot loaders are to avoid case of two different distributions trying different files to EFI over writing each other.
If we were really lucky we could get Microsoft on side to agree to a universal fall back loader. So ending the I am stomping on you and you are stomping on me when upgrading stuff. We have had that universal stomping with MBR for years.
What is needed as well is a EFI setting restore loader. Prefered done in some from of provider netural way.
So 2 Linux Foundation loaders. The restore settings loader is the one to prevent returning to the old age of MBR stomping on install.
Pingback: You'll be able to install Linux on most Windows 8 PCs
Hello, James, will this solution be available for ARM devices running Windows RT, or is it limited to x86 devices only?
It’s limited by my ability to build. Currently I only have an X86-64 UEFI build environment, but in principle it would work.
Excellent news! That is really an excellent solution for small distros and independant distro builders. Can’t wait until tomorrow to build some test images 🙂
James, is the “present user” test a CAPTCHA type? Can one be sure that it is secure enough that it can’t be defeated by malware authors, and thus having the signed stub be incorporated into malware? If such happens, would the LF key be revoked?
Present user test is simply select Yes instead of the default No in a menu.
It can’t be defeated without gaining control of the keyboard which requires either you’ve broken UEFI security, or you already have physical access to the system
Pingback: Linux Is Now Safe from Microsoft’s UEFI : Febryadi.com
Pingback: Archiwum Jak uruchomić Linuksa na nowych „bezpiecznych” komputerach z Windows 8? Bez Microsoftu się nie obejdzie
Pingback: La Linux Foundation aggira il Secure Boot - Netbook News
Pingback: Microsoft Breaks the Web and Linux | Techrights
Pingback: The Linux foundation Develops A System To Install Open Source Operating Systems On Windows 8 Certified PCs
Pingback: ‘Stop-gap’ way to get Linux on Windows 8 machines to be issued | Install Ubuntu
Pingback: Linux Foundation je pronašao lijek za UEFI! - b4sh-blog.orgb4sh-blog.org
Pingback: ‘Stop-gap’ way to get Linux on Windows 8 machines to be issued :: WES Computing
Pingback: Episode 778 – UEFI boot, DoD Cyber RoE, Reading Someone else’s E-mail NOT ilegal, IDing Crims, Telco Security Failings | InfoSec Daily
Pingback: Měsíční souhrn ze světa LINUX | IT MooV.eu
Is this a joke? A unique key will boot ALL machines equipped with UEFI?
Such was my reaction upon reading the announcement. If this is true, it cannot be called by any means a security measure.
Politics are funny sometimes, such as when The Linux Foundation “welcomes efforts by some of the major distributions” to take full advantage of a security chain which they admit to having broken just a little earlier in the same parfor all of us, agrafor all of us, ph. A little hypocrisy doesn’t count that much in the grand scheme of things though, thumbs up to them for having broken UEFI in a way that allows anything to boot, not just some malware, because it was inevitable.
Well congratulate them on their good work [of breaking it first] then.
Pingback: El porque del retraso del Secure Boot de la Linux Foundation
Pingback: Dieter Adriaenssens: Roundup of FOSDEM 2013 | PHP World
Linux should repair system in Secure Mode turned on like Windows 8 does.
Maybe in the future will be… it would be GREAT!