[Discuss] Disabling UEFI and dual booting Linux and Windows

[cra at WPI.EDU (Chuck Anderson)]

On Mon, Dec 10, 2012 at 11:29:35AM -0500, Will Rico wrote:
> I've been trying to following the UEFI / "Secure Boot" conversation
> on this list and can't say I'm successfully following it.  Here are
> a couple of observations / questions:
> 
> 1.  If very smart and experienced people on this list are saying
> things like "What follows is my understanding of Secure Boot and it
> may not be entirely accurate," then how are typical end users
> supposed to deal with this?

By trusting that their distro provider made things easy and obvious
for them, and possibly reading their distro's Release Notes and other
documentation if necessary.  This is no different than doing any other
operating system install.

> 2.  I've seen discussion of the shim method from the perspective of
> the GNU/Linux distribution provider.  How does this work from the
> end-user perspective?  If I hand out a GNU/Linux DVD, what
> instructions do I need to provide them with beyond what I would say
> when giving a DVD to someone on a non-"Secure Boot" system?

For the Red Hat/Fedora world, Garrett's shim takes care of everything
for you as long as you stick to vendor boot images, kernels, and
kernel modules.  If you want to boot a Red Hat- or Fedora-distributed
original DVD on a Secure Boot system, it should just work out of the
box with no requirement that the user do anything different than they
do now.  That was the whole point and design goal of going with that
method, despite resistance by some that Red Hat was "selling out to
Microsoft" by participating in their signing system.

If you want to boot custom kernels or use third-party kernel modules,
then you probably have to learn more.  For ATI, Nvidia, VirtualBox, or
other closed-source driver users, this might mean more pain.

http://mjg59.dreamwidth.org/17542.html

> 3.  If the purpose is to prevent a malicious kernel from installing
> itself (i.e. a kernel that the end-user didn't authorize), why use a
> method based on keys?  Why not simply have the BIOS prompt the user
> with a message like:
> 
> "Warning: A new kernel (operating system) has been detected.  If you
> are installing a new operating system or if you purposefully updated
> your operating system, then this may be OK.  Otherwise, your system
> may have been attacked with a virus or malware.  Are you sure you
> want to boot the new operating system? (y/N)"

Because the uninformed user will always answer "Y".  Any security
system that requires a user to answer a question like that is doomed
to failure.

Besides, that ship has sailed (and rightly so).  UEFI has already
decided on the security architecture.  We now have to live with that.