[Discuss] Fighting UEFI

[tmetro+blu at gmail.com (Tom Metro)]

Richard Pieri wrote:
> Secure Boot is a boon to consumers who just want their appliances to
> work.

This is a valid point, but almost none of your arguments support it,
because the above can be accomplished on a system that both supports
turning off Secure Boot, and loading custom keys.

There may be a long history of vendors locking their systems, but can
you name an example where the lock was not imposed by the hardware
vendor, or by the down-stream customer (like cell phone carriers)?

In this case we have an OS vendor dictating to hardware vendors that
they are not permitted to let other operating systems run on ARM
hardware they make. I believe that sets a new precedent.

Even on x86, where Microsoft doesn't prevent the hardware vendor from
allowing Secure Boot to be turned off, you can bet than many lazy
vendors simply won't implement an option to turn it off, because they
can't be bothered supporting features for small populations. This will
further constrict available hardware choices for non-Windows OSs.

But I'm not sure what the remedy is for that, as the concept for Secure
Boot seems sound, and it doesn't seem right that some outside force (an
FTC lawsuit, for example) should compel Microsoft to include in its
"Windows Hardware Certification Requirements" that hardware vendors
*must* include the ability to turn off Secure Boot. Clearly Microsoft
has no motivation to do this on their own.


> Canonical has a proposal for using Intel's efilinux loader, which is
> signed, to chain-load an unsigned secondary loader like GRUB2 or an
> unsigned kernel image

Better than nothing, but it is still a work-around.

The characteristics of a successful solution are:

1. A novice user can insert a distribution CD (including those produced
by smaller non-profit groups) and be able to boot and install the OS
with no new barriers (i.e. BIOS settings).

2. A technical user is able to either install custom keys or turn off
checks so that they can boot any code they would have been able to run
prior to the introduction of Secure Boot, without needing any new
chained boot loaders.


> Question: how is this at all different from trying to install Linux on a
> compy with a Sony badge on it?  Answer: not in the least.  Linux has
> never been 100% on Sony kit.  Same goes for every other Microsoft
> partner OEM for the last 20+ years.  If Linux isn't an option at ship
> time then there is a chance that something won't work right.

This is obviously a flawed comparison. In the case of incompatibilities,
there is always a chance the next version of the kernel will support the
hardware, even if reverse engineering proprietary hardware is necessary.

In the case of Secure Boot the hardware/firmware is proactively
prohibiting the use of the non-Windows OS. No future OS update (other
than using flaws to subvert the Secure Boot implementation) can resolve
that.


> If you buy a computer that ships with Windows expecting to install Linux
> on it then it's your own damned fault when it doesn't work.  You didn't
> do your research before swiping the plastic so you have nobody to blame
> but yourself.

Generally the wise thing to do - research the compatibility of target
hardware. However, Linux has gotten to the point where it mostly works
on most hardware, so I wouldn't blame someone for having the expectation
that Linux should - for the most part - just work. (As was pointed out,
there's a big difference between something cosmetic not working and the
OS not being able to boot.)

The real issue at hand is what happens if the selection of available
hardware vastly constricts as a result of Secure Boot? It's looking like
this will be a problem for ARM, but with it being an emerging market, it
won't impact existing users. With x86 it seems unlikely that most
vendors will lock out Linux, but that may be in part due to the noise
Linux activists are currently raising over this situation you've
characterized as FUD.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/