1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
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
TO ADD:
parallels with TC
anti-trust violations
MSFT history
DOS lockout
MBR multiboot lockout
http://techrights.org/2011/09/22/tricks-with-boot-process/
http://techrights.org/2011/09/29/boot-abuse-and-complaint/
http://techrights.org/2009/08/20/linux-mbr-in-vista-7/
http://techrights.org/2011/08/10/biggest-technology-bully/
http://techrights.org/2011/05/08/system-updates-vs-grub/
http://techrights.org/2009/01/24/ms-multi-boot-sabotage/
http://techrights.org/2008/05/15/eula-hyper-on-motherboards/
http://www.freesoftwaremagazine.com/columns/uefi_and_windows_8_bad_news_gnu_linux
|
