On Wed, Jun 20, 2012 at 04:35:41PM -0400, Richard Yao wrote:
> On 06/20/2012 04:20 PM, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> >> On 06/20/2012 04:08 PM, Greg KH wrote:
> >>> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >>>> I know that there is a great deal of discussion on the effect that
> >>>> UEFI Secure Boot will have on us. As far as I know, Secure Boot is
> >>>> implemented in the UEFI firmware and if we replace the firmware,
> >>>> Secure Boot issues disappear.
> >>> Stop right there. That's just not going to happen, sorry. You aren't
> >>> going to be able to get a user to replace their BIOS, nor should you
> >>> ever want to. You are not going to be able to keep up with the
> >>> hundreds, if not thousands, of different motherboards being introduced
> >>> every month, in order to just get rid of the secure boot option.
> >> OpenWRT does that with routers and Cyanogenmod does that with phones.
> > No, neither of them replaces the BIOS in their machines with an
> > opensource version. There is no BIOS in those platforms, it's just
> > uboot or fastboot, the PC-like ecosystem is so vastly different it's
> > laughable.
> The BIOS on our machines is analogous to the flash on those machines on
> which the firmware operates. There is no difference.
There is a huge difference here, please do a bit of research before
> >> It seems reason for us to offer it as an option to users. With that
> >> said, this probably won't happen. One of the Core Boot developers
> >> informed me of what is involved in setting up the address space and it
> >> is infeasible for us to do.
> > And I agree with that developer.
> > Don't get "replace all of userspace and the kernel" confused with
> > "replace the UEFI bios". You do realize that the UEFI bios is at least
> > double the size of the Linux kernel, with custom device drivers and tons
> > of other stuff in there? Good luck replacing that...
> Replacing UEFI does not mean that we need a compatible replacement.
> Things like being able to boot Windows is unnecessary functionality that
> can be removed. The only thing replacement firmware must do is get the
> kernel loaded into memory, initialize the structures that the kernel
> wants and jump into it. That is it.
A BIOS does much much more than just that. See the coreboot code for
examples of what needs to happen to get a x86-like machine up and
running to the point at which it is possible to hand off control to a
> >>> And I want secure boot on my machines, with a key I trust, don't you?
> >>> If not, why not? I know lots of others that also want this, why deny
> >>> them the ability to run Gentoo on their hardware?
> >> To be clear, I was not talking about taking away options from users. I
> >> was talking about giving them options.
> > You are taking secure boot out of their systems, that sounds like taking
> > away an option to me :)
> I have an Asus motherboard that fails to boot when it has more than 6
> hard drives. If I replaced its BIOS with our own firmware, I could fix
> that. If I had our own firmware and I wanted to do my own key signing, I
> could implement that.
> If were to replace UEFI with our own firmware, the user would have full
> view of the source code, rather than some mystery blob. The pool of
> people who could do bug fixes would increase and that in general would
> be a good thing.
You do realize that the majority of the UEFI code is opensource, right?
That's not the hard part here, the response from the coreboot developer
should have given you a glimpse into the real difficulties involved.
> Technical hurdles will likely prevent this unless we an get vendors to
> release documentation. Is there any chance you could contact people at
> Intel requesting programming documentation on their memory controller
> and anything else we would need to write a small OS that we could flash
> in place of UEFI?
Again, see the response from Peter about what is needed here. That
"anything else" is not trivial.
But feel free to prove me wrong, I love it when that happens :)