From 113734fd2ab7c3fa703d275ea94e9a16db7ad398 Mon Sep 17 00:00:00 2001 From: P. J. McDermott Date: Sun, 06 Nov 2011 01:42:43 -0400 Subject: Add notes on UEFI Secure Boot. --- diff --git a/topics/secure-boot.txt b/topics/secure-boot.txt new file mode 100644 index 0000000..9020645 --- /dev/null +++ b/topics/secure-boot.txt @@ -0,0 +1,63 @@ +UEFI + Unified Extensible Firmware Interface + supposed to be next-generation boot firmware interface + doesn't replace BIOS; can be implemented on top of BIOS or other firmware + source: http://www.uefi.org/about/ +Secure Boot + defined in latest UEFI spec (2.3.1) + designed to prevent "bootkits" between the firmware and the OS + uses public key cryptography to implement a "verified software stack" + verifies signatures of bootloaders and firmware images on HW components + requires that only "approved" software may boot + UEFI spec says Secure Boot is optional +Microsoft Windows 8 logo program + requires that OEMs enable Secure Boot +Red Hat became aware of this in early August +Matthew Garrett first reported the issue 2011-09-20 + http://mjg59.dreamwidth.org/5552.html + expressed concern that many OEMs won't allow users to disable Secure Boot +Steven Sinofsky of MSFT responded 2011-09-22 + http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx + specified that OEMs must control the Platform Key + only OEMs can sign software and firmware + "supports OEMs having the flexibility to decide who manages security certificates and how to allow customers to import and manage those certificates, and manage secure boot" + essentially: + it's up to OEMs to decide if users can run their own OSes + "it's not our fault if we're a monopoly" +Matthew Garrett responded to MSFT's response 2011-09-23 + http://mjg59.dreamwidth.org/5580.html + Windows 8 certification doesn't require OEMs to allow users to disable Secure Boot + some OEMs have told RH that they won't allow users to disable Secure Boot + loss of freedom: + some hardware won't allow users to run non-MS OSes/bootloaders + some hardware won't allow users to change hardware components + (graphics card, SATA controller, network card, etc.) + MSFT is misusing a useful feature of UEFI to put control in OEM hands + MSFT hasn't denied anything +FSF campaign and statement, 2011-10-13 + http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot + when done correctly (allowing user to authorize programs), useful feature + MS and OEMs might implement restrictions such that users can't run non-MS SW + OEMs must allow user to either disable Secure Boot or install a free OS + alternative: + complicated and risky measures to circumvent restrictions + the end of reviving old HW with GNU/Linux: more electronic waste + connections with OEMs = giant advantage for proprietary OS companies + petition to OEMs with 20,000 signatures so far +RH, LF, and Canonical have written a white paper, 2011-10-28 + notes that most PCs will likely ship with Secure Boot in Q1 2012 + highlights implications of Secure Boot + makes recommendations to OEMs to ensure users remain in control of their PCs + http://blog.canonical.com/2011/10/28/white-paper-secure-boot-impact-on-linux/ + http://www.redhat.com/about/news/blog/red-hat-the-linux-foundation-and-canonical-publish-white-paper-on-unfied-extensible-firmware-interface +ZDNet's Ed Bott contacted Dell and HP, 2011-11-02 + http://www.zdnet.com/blog/bott/leading-pc-makers-confirm-no-windows-8-plot-to-lock-out-linux/4185 + "Dell has plans to make SecureBoot an enable/disable option in BIOS setup" + (as demanded by FSF) + HP largely unaware of the issue and still focused on Windows 7 + AMI "will advise OEMs to provide a default configuration that allows users to enable / disable secure boot, but it remains the choice of the OEM to do (or not do) so" +"lucas maximus" of OSNews responded to Ed Bott, 2011-11-03 + http://www.osnews.com/story/25293/Dell_HP_Respond_to_Secure_Boot_Issue + notes that "having plans" isn't definitive, but is at least reassuring + HP wasn't aware of the issue, so the response is a general empty PR statement + nothing from Dell, HP, or AMI is reassuring -- cgit v0.9.1