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 |