| 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? |
Archives