[Discuss] Disabling UEFI and dual booting Linux and Windows

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

State of Secure Boot detailed
http://www.h-online.com/security/news/item/State-of-Secure-Boot-detailed-1741460.html

  Red Hat and Fedora developer Matthew Garrett has detailed the "range
  of subtle changes" that have taken place since he began working on
  Secure Boot support. In a blog posting, Garrett gives an overview of
  the current implementation. He explains that the current approach, a
  shim bootloader, "cunningly called 'Shim'", contains a public key
  under their own control and is signed by Microsoft. The shim will only
  boot binaries signed with the public key and allows the developers to
  build and sign all other binaries themselves without going back to
  Microsoft to get bootloaders or other components signed.

  Garret points out that a locked-down boot environment and signed
  kernel do block modified bootloaders and booting attack code, but do
  nothing if, for example, an attacker uses a booted kernel to launch
  another kernel. To ensure that doesn't happen, direct hardware access
  from userspace is blocked and must go through kernel modules which
  have been signed by a key the kernel trusts.
[...]
  To assist other distributions, the shim will also notice if the second
  stage bootloader is signed with a key it doesn't recognise. If it is,
  users will have the option of enrolling a new key from install media
  and having it added to a trusted key list. There is also, now, the
  capability to deactivate signature validation in the shim so
  developers need not sign kernels they are developing; it requires a
  reboot and a user generated password to be activated.


Delays beset the Linux Foundation's Secure Boot workaround
http://www.pcworld.com/article/2015527/delays-beset-the-linux-foundations-secure-boot-workaround.html

  On Tuesday...James Bottomley, chair of the Linux Foundation's
  Technical Advisory Board, admitted that the effort was not progressing
  as quickly and smoothly as had been originally hoped.

  "We have the code for the Linux Foundation pre-bootloader in place,"
  Bottomley wrote in a blog post. "However, there was a delay while we
  got access to the Microsoft signing system.

  "I'm still not sure what the actual problem is, but ... I suspect that
  the binary is signed with a generic Microsoft key instead of a
  specific (and revocable) key tied to the Linux Foundation," Bottomley
  explained.


Linux Foundation support for booting Linux on Windows 8 PCs delayed
http://www.zdnet.com/linux-foundation-support-for-booting-linux-on-windows-8-pcs-delayed-7000007673/

  The plan was, as James Bottomley, Parallels' CTO of server
  virtualization and well-known Linux Kernel maintainer, explained on
  October 10th, 2012, to "obtain a Microsoft Key and sign a small
  pre-bootloader which will, in turn, chain load (without any form of
  signature check) a predesignated boot loader which will, in turn, boot
  Linux (or any other operating system)."

  This "pre-bootloader employ a 'present user' test to ensure that it
  cannot be used as a vector for any type of UEFI malware to target
  secure systems.
[...]
  Bottomley...told me "We're all done and dusted with the signed
  contract with Microsoft and the binary ready to release.  However,
  I've been having bizarre experiences with the Microsoft sysdev
  centre."

  Specifically, "The first time I sent the loader through, it got stuck
  (it still is, actually). So I sent another one through after a week or
  so. That actually produced a download, which I've verified is signed
  (by the MS UEFI key) and works, but now the Microsoft sysdev people
  claim it was "improperly" signed and we have to wait for them to sort
  it out. I've pulled the binary apart, and I think the problem is that
  it's not signed with a LF [Linux Foundation] specific key, it's signed
  by a generic one rooted in the UEFI key."


I see the value in having signed boot loaders, but it seems rather
problematic that Microsoft has assumed the role of keymaster over the
keys that get installed into hardware manufactured by third parties, and
acting as a gateway to its operating system competitors. It seems
inevitable that if they don't hand over that responsibility to an
independent third party, they'll likely be facing another FTC lawsuit.

 -Tom

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