[Linux-aus] Fwd: What is LA's response to UEFI Secure Boot?

[Russell Coker]

On Sun, 5 Aug 2012, Adam Nielsen <a.nielsen at shikadi.net> wrote:
>    3. Secure Boot is great, providing we have control over the keys our
>       equipment recognises as valid.
> 
> My personal position is the last one.  I think Secure Boot could work well,
> if  I can remove the Microsoft keys (since they're bound to be compromised
> sooner or later) and install my own, only allowing my chosen Linux kernels
> to boot and nothing else.

For the personal use of people like me a solution could involve typing in a 
string of 32 hexadecimal digits.  For the general public that won't work.

So merely having control over the keys isn't adequate if the usability issues 
prevent most people from being able to perform reasonable tasks such as 
installing a random distribution of Linux.

Secure boot should be relatively easy to turn off by authorized people.  Years 
ago it was common to have a keyboard lock on the front of a PC.  Turn the key 
and no-one can type on an AT keyboard that's connected.  It wouldn't be 
difficult to design a PC in a similar manner, turn the physical key and you 
can install an OS without a RSA key - or update the BIOS set of keys in some 
easy manner.

The Red Hat solution of paying money to MS for a signature on their boot 
loader is a reasonable solution for them, but it's bad for Linux companies to 
be forced to pay money to MS.  Just imagine how MS would complain if they had 
to pay money to a company like IBM for signatures.  If the first IBM PC had 
such a boot lock then MS might not even exist as we know it today.

On Sun, 5 Aug 2012, Brent Wallis <brent.wallis at gmail.com> wrote:
> I also have questions around virtual bootloaders....
> 
> Will UEFI eventually be implemented in hypervisors?

I had the impression that someone had already written such support for testing 
UEFI booting.  But in terms of actual use, why bother?  With Xen or KVM you 
can boot a kernel that's stored outside the virtual machine environment.  In 
that case any trojan running in the VM can't attack it and any trojan that can 
attack it can probably do something worse than just attacking one VM.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/