Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Fighting UEFI



On Sat, Jul 28, 2012 at 06:23:12PM -0400, Guy Gold wrote:
> On Sat, Jul 28, 2012 at 3:50 PM, Chuck Anderson <cra at wpi.edu> wrote:
> >
> > 1. Disable Secure Boot in the firmware.
> 
> The horror stories I've heard, informed, that there will not be such an option
> to disable, one the system was purchased with it,  true/false ?

False for x86, true for ARM.  See Microsoft's "Windows Hardware
Certification Requirements: Client and Server Systems" document
updated July 2, 2012:

http://download.microsoft.com/download/a/d/f/adf5bede-c0fb-4cc0-a3e1-b38093f50ba1/windows8-hardware-cert-requirements-system.pdf

which says in the introduction:

  This document contains the Windows Hardware Certification
  requirements for Windows 8 certified systems. These requirements are
  Microsoft's guidelines for designing systems which successfully meet
  Windows performance, quality, and feature criteria, to assure the
  optimum Windows 8 computing experience. Successfully following this
  guidance allows a partner to receive certification for their system.

and on page 121:

  17. Mandatory. On non-ARM systems, the platform MUST implement the
      ability for a physically present user to select between two
      Secure Boot modes in firmware setup: "Custom" and
      "Standard". Custom Mode allows for more flexibility as specified
      in the following:

      a. It shall be possible for a physically present user to use the
         Custom Mode firmware setup option to modify the contents of
         the Secure Boot signature databases and the PK. This may be
         implemented by simply providing the option to clear all
         Secure Boot databases (PK, KEK, db, dbx), which puts the
         system into setup mode.

      b. If the user ends up deleting the PK then, upon exiting the
         Custom Mode firmware setup, the system is operating in Setup
         Mode with SecureBoot turned off.

      c. The firmware setup shall indicate if Secure Boot is turned
         on, and if it is operated in Standard or Custom Mode. The
         firmware setup must provide an option to return from Custom
         to Standard Mode which restores the factory defaults. On an
         ARM system, it is forbidden to enable Custom Mode. Only
         Standard Mode may be enabled.

  18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is
      required to implement the ability to disable Secure Boot via
      firmware setup. A physically present user must be allowed to
      disable Secure Boot via firmware setup without possession of
      PKpriv. A Windows Server may also disable Secure Boot remotely
      using a strongly authenticated (preferably public-key based)
      out-of-band management connection, such as to a baseboard
      management controller or service processor. Programmatic
      disabling of Secure Boot either during Boot Services or after
      exiting EFI Boot Services MUST NOT be possible. Disabling Secure
      Boot must not be possible on ARM systems.

> > 2. Load your own keys into the firmware.
> >
> > 3. Pay $99 to Verisign so you can sign as many binaries as you want
> >    and have them automatically be trusted by the default firmware
> >    keys.
> 
> Is it a one time payment one would need to make, and then - he can
> re-purpose any
> machine that he comes across, or, is it 99$ - per every  machine he
> comes across ?

The one time payment gives you the ability to use Microsoft's signing
infrastructure to sign as many binaries as you like with a key that is
signed by Microsoft, and hence trusted by any manufacturer's hardware
who trusts Microsoft-signed keys (i.e. just about all of them).

But, if you do Bad Things(TM) with that ability (like allow unsigned
binaries to be loaded by your signed bootloader, or allow unsigned
kernel modules to be loaded into your signed kernel, or leak your
private keys), your key will likely get revoked by Microsoft.

More details:

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



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org