Re: Of course! @Stuart
Please explain how Secure Boot is destined to become more of a headache than the problem it tries to solve.
On paper, Secure Boot looks good. It has a number of flaws though.
Secure Boot requires that the boot loader be signed by a key known to the UEFI firmware before being permitted to boot. This therefore implies that the device must be pre-loaded with the public keys of known publishers before it ships to the customer.
Thankfully on x86, the requirement is that the user must be able to add their own keys. This is not a trivial process however and differs between UEFI implementations. So immediately, anyone who has a desire or need to run an OS other than one of the select few, has a few more hurdles to jump over.
Ever tried getting into the UEFI setup on a modern x86 machine? You need lightning quick reflexes, and an educated guess as to what button to hit! Been there, done that on a few machines.
Moreover, this assumes that the private key for the publisher you use does not get compromised. The moment that happens, sure, they can revoke that key but then:
- the old kit will still recognise and accept that compromised key, until such time their firmware gets updated (How often do people here update their boot firmware I wonder? How many devices will never have updates provided?)
- someone's legitimately paid-for OS suddenly stops working on newer hardware, that WILL get people upset.
Others have pointed out that there is a lot of code in the UEFI kernel. Matthew Garett claimed as much as 100MB of source code in TianoCore which is the reference UEFI implementation. If you've got the time, have a look at the whole video (I watched the presentation in person).
As a matter of interest:
RC=0 stuartl@vk4msl-mb /tmp $ tar -xJf /home/portage/distfiles/linux-3.14.tar.xz
RC=0 stuartl@vk4msl-mb /tmp $ cd linux-3.14/
RC=0 stuartl@vk4msl-mb /tmp/linux-3.14 $ find . -type f -a \! \( -name \*.h -o -name \*.c \) -delete
RC=0 stuartl@vk4msl-mb /tmp/linux-3.14 $ du -hs .
So just under one fifth of the entire Linux kernel. UEFI runs on i386, AMD64 and ARM to my knowledge. Linux runs on that and some, including obscure machines most have never heard of.
Two facts of life:
- people write code
- people make mistakes
Therefore, there will be lots of bugs in that UEFI code, including the stuff that implements Secure Boot. There is a lot of complexity to debug which will seem foreign to the old-hands used to the ye olde BIOS when things go wrong.
With the rush to get things to market, you can bet your bottom dollar that manufacturers won't be testing their code to ensure it's safe from malware (the intended target for Secure Boot), but you can guarantee the blackhats will! I therefore believe that while there were some noble ideas in Secure Boot, it in all probably will not achieve what it ultimately set out to achieve, and will instead cause grief with all the additional things that can go wrong.