UEFI and Linux in 2013 - the list so far

[40hz]

With the advent of UEFI enabled PCs now being shipped, Linux users who wish to easily dual-boot Linux and Windows 8 on such machines currently have relatively few options.

Secure Boot distribution support
Dec. 27th, 2012 07:02 pm
by Matthew Garret

It's after Christmas, and some number of people doubtless ended up with Windows 8 PCs and may want to install Linux on them. If you'd like to do that without fiddling with firmware settings, here are your options...

<read the rest here>

So far, the list of UEFI collaborating distros is pretty short:

• Ubuntu 12.10
• Fedora 18
• Sabayon

Hmm...the only real surprise there is Sabayon. Whoulda thought?

Suse has announced plans to come to some sort of accomodation with Microsoft; and Debian has announced they will put support for UEFI into their installer, but (so far) do not actually support UEFI.

-----

ADDENDUM:

GParted - that most excellent of all disk partitioning and management toolkits now has full support for UEFI on their latest live distribution. This is welcome news as GParted Live is one of the most useful utility disks in a PC tech's toolkit.

From the GParted website:

28 December 2012: GParted Live 0.14.1-6 Stable Release

The GParted team is proud to announce a new stable release of GParted Live.

The big news with this release is the added ability to boot the live image on UEFI firmware computers, while maintaining boot ability on traditional PC/BIOS computers. This means that GParted Live can now boot on newer Windows 8 computers.

In addition to supporting uEFI firmware, two more GNU/Linux operating system images have been released: i686-PAE (Physical Address Extension) and AMD64 (X86-64). These new images permit addressing more than 4 gigabytes of RAM, and enable using multiple processor cores.

Other items of note include:

   Updated Linux kernel to 3.2.35-2
   Based on the Debian Sid repository (as of 2012/Dec/23)

Thanks goes to Steven Shiau for these live image enhancements.

Curtis

[f0dder]

IMHO it doesn't seem so difficult to get Secure Boot support - you just use Matthew Garrett's shim?

If you feel you need to be able to recompile the shim, you spend $100 on a VeriSign SSL/CodeSigning certificate, and use that to sign up for a (free) Microsoft SysDev account, which will let you sign stuff.

And while I haven't seen any "ready for Win8" laptops, so I cannot comment on the key management features of their BIOS/UEFI, my Secure Boot capable ASUS P8Z77-V PRO motherboard has full key management capabilities.

I still do believe that Secure Boot is fundamentally a good thing, technically... but I don't like the thought of the slippery slope.

[zridling]

I can't believe the industry linked its future to this MS-exclusive approach. Is the only way around it to build your own rigs? (Helped a relative build one over the holidays and we just turned the UEFI option off before installing Linux on a new HD.

[f0dder]

It's not MS-exclusive, Zaine. And as long as you're buying x86 and not ARM, it's a MS requirement that your UEFI either has key management facilities, or at least allows disabling secure boot, in order to get the MS logo thingy.

Let's stop the FUD and stick to facts - but still keep the slippery slope in mind.

[Notok]

I'm not sure that I understand the slippery slope thing here. The UEFI is an independent panel. MS is on the panel, but they're just one voice; I don't imagine them all deciding to make all computer hardware Windows-only. They are basically like the hardware equivalent of SSL certificate publishers. Like f0dder said, Windows 8 certification requires that you be able to disable Secure Boot, and that certification is important to OEMs.

[f0dder]

The UEFI is an independent panel.

Independent panel, yes, but there's some pretty strong individual forces on it... and I somehow think it's telling that the file format used for UEFI executables is Microsoft's Portable Executable format.

Also, Windows 8 cert requires that you can disable Secure Boot - there's no guarantee that 9 or 10 will require that, once people have accepted Secure Boot as a technology. It's something to be wary of, at least.

[zridling]

How about building a better OS instead of locking down hardware? Unless, Win8 ain't what MS claims it is.

[f0dder]

How about building a better OS instead of locking down hardware? Unless, Win8 ain't what MS claims it is.

The hardware isn't locked down for x86, only for their ARM tablets (and yes, that is bad IMHO).

Secure Boot itself is IMHO a good idea, it offers yet a level of protection against malware (it's not an end-all-be-all solution and it has flaws, but security is both depth and breadth). Yes, I am worried that SB might be used to lock down x86 hardware in the future, but claiming that's it's only point is FUD.

[Carol Haynes]

Also, Windows 8 cert requires that you can disable Secure Boot

Where does it say that? I thought W8 cert required that SB had to be enabled by default and that it was up to individual OEMs whether they allow disabling SB.

[40hz]

Yes, I am worried that SB might be used to lock down x86 hardware in the future, but claiming that's it's only point is FUD.

I think categorizing that purely as FUD risks being guilty of being it's own piece of FUD.

In case anybody has any doubts of Microsoft's attitude and intentions when it comes to UEFI (despite Redmond's promises of an easy process for those who wish to obtain a validly signed pre-boot loader) take a look at this article over at ZDnet.

Linux Foundation UEFI Secure Boot key for Windows 8 PCs delays explained

Thanks to Microsoft, the Linux Foundation's program for booting Linux easily on Windows 8 PCs protected with Secure Boot is still stuck in neutral.

By Steven J. Vaughan-Nichols for Linux and Open Source | November 23, 2012 -- 18:43 GMT (10:43 PST)
Follow @sjvn


The Linux Foundation is sorry to report that its project for making Linux easy to boot with Windows 8 Secure Boot still isn't finished.

James Bottomley, Parallels' CTO of server virtualization, well-known Linux kernel maintainer, and the man behind the Linux Foundation's efforts to create an easy way to install and boot Linux on Windows 8 PCs with UEFI (Unified Extensible Firmware Interface) Secure Boot enabled is sorry to report that "We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader."

Despite the best efforts of Fedora, openSUSE, Ubuntu, and the Linux Foundation, booting Linux on UEFI Secure Boot Windows 8 PCs continues to be a problem . The easiest way to avoid Windows 8 lock-in is to disable UEFI Secure Boot from your system before it starts to boot. However, this option may not be available on all motherboard; isn't available at all on Windows RT devices, such as the Surface; and is still troublesome even with Secure Boot disabled. So, it is that the struggle—and struggle it is—to create an easy to use, universal install and boot Secure Boot Linux installer continues on.

<more here>

It's gotten so ridiculous and obvious that even The Linux Action Show (which argued for a "wait & see" approach to UEFI and suggested Microsoft be given the benefit of the doubt) are finally getting frustrated. Fast forward to the 16:55 mark in the below video to hear what's been going on with the Linux Foundation's attempt to work Microsoft on this.

https://www.youtube.com/watch?v=c0SOWn80nJo

[f0dder]

Also, Windows 8 cert requires that you can disable Secure Boot

Where does it say that? I thought W8 cert required that SB had to be enabled by default and that it was up to individual OEMs whether they allow disabling SB.

Grab the "Windows 8 System Requirements" PDF, and jump to page 121. A few selective quotes:

17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

This is system requirements for Windows 8, though, and there's no guarantee the next Windows will have the same requirements - that's the slippery slope problem.

Yes, I am worried that SB might be used to lock down x86 hardware in the future, but claiming that's it's only point is FUD.

James Bottomley, Parallels' CTO of server virtualization, well-known Linux kernel maintainer, and the man behind the Linux Foundation's efforts to create an easy way to install and boot Linux on Windows 8 PCs with UEFI (Unified Extensible Firmware Interface) Secure Boot enabled is sorry to report that "We’re still waiting for Microsoft to give the Linux Foundation a validly signed pre-bootloader."

Humm, are they still waiting? And if so, what makes them special compared to other people? There's already a signed shim that'll let you SecureBoot anything.

EDIT: also, for what it's worth, my ASUS P8Z77-V PRO motherboard supports Secure Boot, and has a crapload of key management features. But my box is obviously home-built, not Win8 certified.

[40hz]

what makes them special compared to other people?

The Linux Foundation is attempting to work with Microsoft and its implementation of SecureBoot rather than hack around it. The shim is a hack - and potentially open to misuse and mischief.

What makes the Linux Foundation different from many in the Linux community is that, rather than declare war, they have opted to take Microsoft up on its supposed offer to provide a path for peaceful coexistence when it comes to UEFI/SecureBoot. One in which all modern PC operating systems can take advantage of - and equally benefit from - the purported increases in security it provides.

Please remember that Linux got burned over the so-called ACPI "standard." Most distros chose to ignore the broken power management implementation Microsoft was championing since APM worked fine just as it was. Unfortunately, the gravity well created by Microsoft's share of the market had most hardware manufacturers migrate over to Microsoft's own implementation of "standard" ACPI and abandon APM thereby forcing Linux kernal maintainers to switch over to not only ACPI - but Microsoft's own take on it in order for it to work with most laptops. As was noted in The Linux Action show above, this is still a problem in the Linux world. And many there feel UEFI  threatens to become a similar issue down the road since Microsoft is effectively making all the calls in this particular game.

I think, in all fairness, that the UEFI/SecureBoot initiative has more to do with business strategy and less to do with enhancing security than is being admitted. At least so far as the way it is currently being administrated by Microsoft. Because if the real goal was to further enhance security, it would be in everyone's best interest if it be adopted and deployed as quickly as possible industry-wide.

The simple fact that Microsoft is inserting technical hurdles and gotchas into the mix smacks a little of the old strategy of making sure Lotus 1-2-3 got broken with each new version of DOS since Microsoft had a competing spreadsheet (Multiplan/Excel) they were trying to gain traction with.

And insisting on not allowing GPL licensing or its equivalents on a so-called "open" standard they're pioneering seems to be more than a little disingenuous. Especially since Microsoft has (to date) refused to go on record as saying exactly what their objections to that would be. Likely they don't want to because Microsoft's insinuation that the provisions of GPL could be used to force manufacturers and Microsoft to reveal signing keys is totally bogus. And they know it. Something which has been repeatedly addressed by The Linux Foundation itself, which has clearly explained why it would not.

Microsoft is in the same fix as Sun Microsystems is with Java. Both want to have something they can call an "open standard" but still have full control and the last word over.

Last I heard, "open" doesn't work that way.