All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@google.com>
To: Alexander Graf <agraf@suse.de>
Cc: Michael Chang <mchang@suse.com>,
	The development of GNU GRUB <grub-devel@gnu.org>,
	 Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	 Peter Jones <pjones@redhat.com>,
	Benjamin Brunner <bbrunner@suse.de>
Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
Date: Fri, 11 Jan 2019 11:32:19 -0800	[thread overview]
Message-ID: <CACdnJuug2D=UFnvRrQtfVXGhndfKES5iqd4d9ghZhWnWBPdGYw@mail.gmail.com> (raw)
In-Reply-To: <1CE00885-C88C-4D0C-B41C-3BBDDB65F716@suse.de>

On Thu, Jan 10, 2019 at 12:59 AM Alexander Graf <agraf@suse.de> wrote:
> So really dumb question here: What if we didn't use the MS key? What if instead, we just provide a SUSE/openSUSE key and give customers the ability to sign their own grub+Linux binaries?

Then you end up blocking install of any Linux distribution that isn't
big enough to have every ARM server vendor include their keys. This is
the exact reason we chose not to explore this approach on x86 - we
didn't want Red Hat to have privileges that, say, Gentoo didn't. The
problem is somewhat mitigated if systems are guaranteed to be shipped
with Secure Boot disabled, but you then still end up encouraging
vendor lock-in - it becomes difficult to migrate systems from one
distribution to another without manual re-keying.


  parent reply	other threads:[~2019-01-11 19:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  8:12 Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM Michael Chang
2019-01-10  8:59 ` Alexander Graf
2019-01-11 10:58   ` Leif Lindholm
2019-01-11 14:17     ` Ard Biesheuvel
2019-01-14  7:30       ` Michael Chang
2019-01-14  7:41         ` Ard Biesheuvel
2019-01-14  9:53           ` Michael Chang
2019-01-14  9:57             ` Ard Biesheuvel
2019-01-14 11:09               ` Michael Chang
2019-01-14  4:58     ` Michael Chang
2019-01-14  7:07       ` Ard Biesheuvel
2019-01-14  9:14         ` Michael Chang
2019-01-14 10:22           ` Alexander Graf
2019-01-22  5:00             ` Michael Chang
2019-01-14 18:42           ` Peter Jones
2019-01-22  6:24             ` Michael Chang
2019-01-14 15:27         ` Peter Jones
2019-01-14 10:25     ` Alexander Graf
2019-01-11 19:32   ` Matthew Garrett [this message]
2019-01-11 19:49     ` Alexander Graf
2019-01-22  6:35       ` Michael Chang
2019-01-22  9:11         ` Alexander Graf

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='CACdnJuug2D=UFnvRrQtfVXGhndfKES5iqd4d9ghZhWnWBPdGYw@mail.gmail.com' \
    --to=mjg59@google.com \
    --cc=agraf@suse.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bbrunner@suse.de \
    --cc=grub-devel@gnu.org \
    --cc=leif.lindholm@linaro.org \
    --cc=mchang@suse.com \
    --cc=pjones@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.