grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Colin Watson <cjwatson@ubuntu.com>
To: grub-devel@gnu.org
Subject: Re: [PATCH] Add linuxefi module
Date: Tue, 21 Jan 2014 13:43:57 +0000	[thread overview]
Message-ID: <20140121134357.GA11502@riva.ucam.org> (raw)
In-Reply-To: <CAKCeAn_TnmttA=WZttFcpWgWprYK39YgEeRaRAHewm9p0FBg3g@mail.gmail.com>

On Mon, Jan 20, 2014 at 08:46:48PM -0500, SevenBits wrote:
> On Monday, January 20, 2014, Lubomir Rintel <lkundrak@v3.sk> wrote:
> > From: Matthew Garrett <matthew.garrett@nebula.com>
> >
> > 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.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]


  reply	other threads:[~2014-01-21 13:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-20 23:28 [PATCH] Add linuxefi module Lubomir Rintel
2014-01-21  1:46 ` SevenBits
2014-01-21 13:43   ` Colin Watson [this message]
2014-01-21 13:53     ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-21 15:24     ` SevenBits
2014-01-21 16:24 ` Andrey Borzenkov
2014-01-21 16:29   ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-21 23:29     ` Colin Watson
2014-01-22 15:00       ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-21 16:30   ` Matthew Garrett
2014-01-21 19:20     ` Leif Lindholm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140121134357.GA11502@riva.ucam.org \
    --to=cjwatson@ubuntu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).