Preparing the kernel for UEFI secure boot [LWN.net]

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 9:00 UTC (Fri) by etienne (subscriber, #25256) [Link]

IHMO if you cannot disable 'secure' boot in the beginning you will not be able to install Linux anyway, because you will not be able to boot the DVD containing the distribution (that would be an unverifiable/unsecured boot and no way to check El-Torito bootloader/kernel combined security); same for network booting (start/authorise the booting before receiving the kernel so no way to check it).
For sure you may be able to disable 'secure' boot using a PS2 keyboard (the USB stack will not be completely initialised in time for you to press the magic key on your USB keyboard), once you have guessed which magic key combination to press (displaying that key combination on the screen would not be secure). Unfortunately the PC motherboard manufacturer will remove the PS2 keyboard plug to save money, did you kept your soldering iron?
Moreover, removing/untrusting root means that there is no more any way to debug/repair bad stuff happening, a failing hard disk, a signed but buggy driver on your hardware, a corrupted UEFI FLASH / bad UEFI FLASH checksum, a video card exchanged by the same one but with a different BIOS...

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 10:45 UTC (Fri) by wookey (subscriber, #5501) [Link]

That has two problems. 1) If your machine doesn't have an option to turn secure boot off you are knackered and 2) If you _want_ to be able to secure yourself against malware booting the wrong thing (which is a reasonable thing to want), just turning the feature off isn't ideal.

1) Will happen if your server is ARM-based and the vendor of the hardware wants to make it possible to run Windows. They are not _allowed_ to put the 'disable' feature in the BIOS if they want a 'certified for Windows' sticker. Are vendors going to supply two versions of the hardware - one certified, one not? (Maybe two BIOSes would suffice and you could choose to install the 'generally useful but not certified for Windows' version - so long as one is supplied).

2) Restricted boot is actually useful so long as you have control over which signing keys are accepted. They you can sign your kernels and protect against a set of attacks. It's the control of keys which is the important bit. For things like remote servers I can see this being quite a useful feature for some people, like selinux is.

I really don't know what's going to happen with that ARM restriction. It's not going to be popular with a good chunk of purchasers, especially of server-grade stuff. And it'll be a massive pain on mobile stuff too, although to be fair if you bought mobile hardware running Windows-anything over the last decade you were usually screwed when it cam to putting your own OS on there (for boring difficulty-of-reverse-engineering reasons), so maybe things won't change that much and it'll remain unpopular. The important bit is still 'who controls the keys in the bootloader'.

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 12:25 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

The Windows requirements only cover client, not server, and ARM is currently restricted to client.

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 13:15 UTC (Fri) by pboddie (guest, #50784) [Link]

That state of affairs will only last as long as (1) Microsoft remains aware that the regulatory authorities are still looking and can punish them, and (2) the case can still be made that servers can run different operating systems.

As we already know, Microsoft and others are effective at bamboozling the regulators, judges, the public with the fairy story that a phone or other mobile device, even a laptop, has been fashioned from raw minerals with the sole purpose of running Windows. We not only need to overturn this deception, but we also need to guard against it spreading.

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 13:26 UTC (Fri) by wookey (subscriber, #5501) [Link]

Sorry. I don't really understand that. A computer can be both client and server depending what software I run on it. Do you mean there are different versions of Windows called 'client' and 'server' and the certification requirement of 'cannot switch off restricted boot' only applies to the 'client' version?
Can't you run server software on 'Windows client'? How do they stop that happening? (can you tell I've not taken much notice of Windows for a really long time now)

Presumably they will want Windows to run on ARM server kit so there will be a version of 'Windows server' for ARM soon enough. If that won't have the 'you can't turn off resitricted boot' antifeature certification requirement then thats good.

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 13:35 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

The certification requirements that must be met depend on whether a hardware vendor deems their platform to be client or server, and there's a corresponding set of limitations on the supported versions of Windows. You could run a server on client editions of Windows, but you'd be missing any of the management tools that would make it a reasonable or pleasurable experience.

Preparing the kernel for UEFI secure boot

Posted Sep 7, 2012 18:24 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

If hardware vendors could designate their hardware as 'server' or 'client' and have this enforced, Linux would never have gotten started.

*nix manufacturers would have loved to be able to protect their expensive systems by preventing the cheap systems from running "server" OS versions

Microsoft also would have loved to be able to lock in the 'server' vs 'client' status of hardware

the losers of this are the users and owners of the systems