1 |
On 06/20/2012 04:20 PM, Greg KH wrote: |
2 |
> On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote: |
3 |
>> On 06/20/2012 04:08 PM, Greg KH wrote: |
4 |
>>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote: |
5 |
>>>> I know that there is a great deal of discussion on the effect that |
6 |
>>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is |
7 |
>>>> implemented in the UEFI firmware and if we replace the firmware, |
8 |
>>>> Secure Boot issues disappear. |
9 |
>>> |
10 |
>>> Stop right there. That's just not going to happen, sorry. You aren't |
11 |
>>> going to be able to get a user to replace their BIOS, nor should you |
12 |
>>> ever want to. You are not going to be able to keep up with the |
13 |
>>> hundreds, if not thousands, of different motherboards being introduced |
14 |
>>> every month, in order to just get rid of the secure boot option. |
15 |
>> |
16 |
>> OpenWRT does that with routers and Cyanogenmod does that with phones. |
17 |
> |
18 |
> No, neither of them replaces the BIOS in their machines with an |
19 |
> opensource version. There is no BIOS in those platforms, it's just |
20 |
> uboot or fastboot, the PC-like ecosystem is so vastly different it's |
21 |
> laughable. |
22 |
|
23 |
The BIOS on our machines is analogous to the flash on those machines on |
24 |
which the firmware operates. There is no difference. |
25 |
|
26 |
>> It seems reason for us to offer it as an option to users. With that |
27 |
>> said, this probably won't happen. One of the Core Boot developers |
28 |
>> informed me of what is involved in setting up the address space and it |
29 |
>> is infeasible for us to do. |
30 |
> |
31 |
> And I agree with that developer. |
32 |
> |
33 |
> Don't get "replace all of userspace and the kernel" confused with |
34 |
> "replace the UEFI bios". You do realize that the UEFI bios is at least |
35 |
> double the size of the Linux kernel, with custom device drivers and tons |
36 |
> of other stuff in there? Good luck replacing that... |
37 |
|
38 |
Replacing UEFI does not mean that we need a compatible replacement. |
39 |
Things like being able to boot Windows is unnecessary functionality that |
40 |
can be removed. The only thing replacement firmware must do is get the |
41 |
kernel loaded into memory, initialize the structures that the kernel |
42 |
wants and jump into it. That is it. |
43 |
|
44 |
>>> And I want secure boot on my machines, with a key I trust, don't you? |
45 |
>>> If not, why not? I know lots of others that also want this, why deny |
46 |
>>> them the ability to run Gentoo on their hardware? |
47 |
>> |
48 |
>> To be clear, I was not talking about taking away options from users. I |
49 |
>> was talking about giving them options. |
50 |
> |
51 |
> You are taking secure boot out of their systems, that sounds like taking |
52 |
> away an option to me :) |
53 |
|
54 |
I have an Asus motherboard that fails to boot when it has more than 6 |
55 |
hard drives. If I replaced its BIOS with our own firmware, I could fix |
56 |
that. If I had our own firmware and I wanted to do my own key signing, I |
57 |
could implement that. |
58 |
|
59 |
If were to replace UEFI with our own firmware, the user would have full |
60 |
view of the source code, rather than some mystery blob. The pool of |
61 |
people who could do bug fixes would increase and that in general would |
62 |
be a good thing. |
63 |
|
64 |
Technical hurdles will likely prevent this unless we an get vendors to |
65 |
release documentation. Is there any chance you could contact people at |
66 |
Intel requesting programming documentation on their memory controller |
67 |
and anything else we would need to write a small OS that we could flash |
68 |
in place of UEFI? |