Gentoo Archives: gentoo-dev

From: Greg KH <gregkh@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Killing UEFI Secure Boot
Date: Wed, 20 Jun 2012 21:11:14
Message-Id: 20120620210952.GA32300@kroah.com
In Reply to: Re: [gentoo-dev] Killing UEFI Secure Boot by Richard Yao
1 On Wed, Jun 20, 2012 at 04:35:41PM -0400, Richard Yao wrote:
2 > On 06/20/2012 04:20 PM, Greg KH wrote:
3 > > On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
4 > >> On 06/20/2012 04:08 PM, Greg KH wrote:
5 > >>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
6 > >>>> I know that there is a great deal of discussion on the effect that
7 > >>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
8 > >>>> implemented in the UEFI firmware and if we replace the firmware,
9 > >>>> Secure Boot issues disappear.
10 > >>>
11 > >>> Stop right there. That's just not going to happen, sorry. You aren't
12 > >>> going to be able to get a user to replace their BIOS, nor should you
13 > >>> ever want to. You are not going to be able to keep up with the
14 > >>> hundreds, if not thousands, of different motherboards being introduced
15 > >>> every month, in order to just get rid of the secure boot option.
16 > >>
17 > >> OpenWRT does that with routers and Cyanogenmod does that with phones.
18 > >
19 > > No, neither of them replaces the BIOS in their machines with an
20 > > opensource version. There is no BIOS in those platforms, it's just
21 > > uboot or fastboot, the PC-like ecosystem is so vastly different it's
22 > > laughable.
23 >
24 > The BIOS on our machines is analogous to the flash on those machines on
25 > which the firmware operates. There is no difference.
26
27 There is a huge difference here, please do a bit of research before
28 claiming otherwise.
29
30 > >> It seems reason for us to offer it as an option to users. With that
31 > >> said, this probably won't happen. One of the Core Boot developers
32 > >> informed me of what is involved in setting up the address space and it
33 > >> is infeasible for us to do.
34 > >
35 > > And I agree with that developer.
36 > >
37 > > Don't get "replace all of userspace and the kernel" confused with
38 > > "replace the UEFI bios". You do realize that the UEFI bios is at least
39 > > double the size of the Linux kernel, with custom device drivers and tons
40 > > of other stuff in there? Good luck replacing that...
41 >
42 > Replacing UEFI does not mean that we need a compatible replacement.
43 > Things like being able to boot Windows is unnecessary functionality that
44 > can be removed. The only thing replacement firmware must do is get the
45 > kernel loaded into memory, initialize the structures that the kernel
46 > wants and jump into it. That is it.
47
48 A BIOS does much much more than just that. See the coreboot code for
49 examples of what needs to happen to get a x86-like machine up and
50 running to the point at which it is possible to hand off control to a
51 bootloader.
52
53 > >>> And I want secure boot on my machines, with a key I trust, don't you?
54 > >>> If not, why not? I know lots of others that also want this, why deny
55 > >>> them the ability to run Gentoo on their hardware?
56 > >>
57 > >> To be clear, I was not talking about taking away options from users. I
58 > >> was talking about giving them options.
59 > >
60 > > You are taking secure boot out of their systems, that sounds like taking
61 > > away an option to me :)
62 >
63 > I have an Asus motherboard that fails to boot when it has more than 6
64 > hard drives. If I replaced its BIOS with our own firmware, I could fix
65 > that. If I had our own firmware and I wanted to do my own key signing, I
66 > could implement that.
67 >
68 > If were to replace UEFI with our own firmware, the user would have full
69 > view of the source code, rather than some mystery blob. The pool of
70 > people who could do bug fixes would increase and that in general would
71 > be a good thing.
72
73 You do realize that the majority of the UEFI code is opensource, right?
74 That's not the hard part here, the response from the coreboot developer
75 should have given you a glimpse into the real difficulties involved.
76
77 > Technical hurdles will likely prevent this unless we an get vendors to
78 > release documentation. Is there any chance you could contact people at
79 > Intel requesting programming documentation on their memory controller
80 > and anything else we would need to write a small OS that we could flash
81 > in place of UEFI?
82
83 Again, see the response from Peter about what is needed here. That
84 "anything else" is not trivial.
85
86 But feel free to prove me wrong, I love it when that happens :)
87
88 greg k-h