Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |