grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Add linuxefi module
Date: Wed, 22 Jan 2014 16:00:35 +0100	[thread overview]
Message-ID: <52DFDD13.1@gmail.com> (raw)
In-Reply-To: <20140121232957.GA24596@riva.ucam.org>

[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]

On 22.01.2014 00:29, Colin Watson wrote:
> On Tue, Jan 21, 2014 at 05:29:03PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> This part is from RH "Secureboot" patch. Few things are right about that
>> patch. Whatever signature verifications would need to be integrated with
>> signatures framework (I have some scratch in phcoder/file_types)
> 
> The RH SB patch is not ideal from a pure GRUB point of view.  But
> realistically, in order to actually be useful in the (unfortunate) SB
> ecosystem that exists today where Microsoft is the effective root of
> trust on most mass-market hardware, we need to have a non-GPLv3
> component that is what the firmware actually loads directly, it needs to
> be able to do signature checking in order to chain to GRUB, and it's
> unlikely to be helpful for the signature checking to be implemented in
> two places - so the scheme where GRUB calls out to shim seems to be an
> uncomfortable necessity there.
> 
Distros start shipping signed kernels with signing in EFI way, including
Ubuntu. Similar proposal to add GnuPG signatures was met with scepticism
(if I remember correctly, including from you). On coreboot systems it
can be interesting to verify that kernel came from Ubuntu and the only
current way to do so is EFI-style signature.
> I have no objection to there being some more native mechanism in GRUB
> that works when users take control of their own trust chain; that seems
> entirely consistent with the FSF's goals regarding UEFI.  But I'm having
> trouble seeing how we could make use of it effectively in order to
> bootstrap free operating systems on firmware that only has the Microsoft
> keys in place, which I think is just as important now as the ability to
> run GNU software on proprietary Unixes was back in the 1980s.
> 
> (Unless, of course, you mean that there ought to be something integrated
> into GRUB's signatures framework that would let it optionally call out
> to shim; that would be an interesting possibility.)
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]

  reply	other threads:[~2014-01-22 15:00 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
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 [this message]
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=52DFDD13.1@gmail.com \
    --to=phcoder@gmail.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).