Re: [PATCH] Add linuxefi module

[SevenBits]

On Jan 21, 2014, at 8:43 AM, Colin Watson <address@hidden> wrote:

> On Mon, Jan 20, 2014 at 08:46:48PM -0500, SevenBits wrote:
>> On Monday, January 20, 2014, Lubomir Rintel <address@hidden> wrote:
>>> From: Matthew Garrett <address@hidden>
>>> 
>>> This adds linuxefi module that provides a way to load Linux kernel
>>> and RAM disk image via EFI services with linuxefi and initrdefi
>>> commands, analogous to linux and initrd commands.
>> 
>> Why? What's wrong with the standard linux and initrd commands? They work
>> just fine under UEFI.
> 
> The background to this is that if conditions permit it's helpful to hand
> over to the kernel without calling ExitBootServices first, because it
> allows the kernel to do more of its own quirks handling.  If shim is
> present then it's used for signature verification first, since UEFI
> Secure Boot forbids executing unsigned code before ExitBootServices;
> although this patch is configured such that if shim is missing then no
> signature check is performed (which is probably reasonable for
> upstreaming).
> 
> We're carrying this patch in Debian/Ubuntu too, although I had to
> disable it on i386_efi - I think it failed tests there.  It's a while
> since I checked, and that patch might be obsolete now.  I also have an
> additional fairly trivial patch to add more debugging printfs to
> linuxefi, which I could apply if this is accepted.
> 
> I would be inclined to say that linuxefi should be essentially an
> internal implementation detail, and that linux should forward to
> linuxefi if appropriate.  I was never a particular fan of Matthew's
> approach of adding an entirely new set of commands for it, and we don't
> expose those in the configuration we generate in the Debian/Ubuntu
> packaging.

I would leave it separate, but I guess it doesn’t really matter - let the 
project managers decide, after all - but I know that I prefer the ability to 
set my preferences one way or the other on issues like this rather than have 
the programmers decide for me. If GRUB users, be it end users or Linux 
distribution vendors, want to boot Linux in the way you describe, then let them 
with your patch, but I see no reason to force them to by making making it an 
“implementation detail” when the traditional approach works just fine on UEFI.

> 
> -- 
> Colin Watson                                       address@hidden
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel

signature.asc
Description: Message signed with OpenPGP using GPGMail