From: Colin Watson <cjwatson@ubuntu.com>
To: grub-devel@gnu.org
Subject: Re: [PATCH] Add linuxefi module
Date: Tue, 21 Jan 2014 23:29:58 +0000 [thread overview]
Message-ID: <20140121232957.GA24596@riva.ucam.org> (raw)
In-Reply-To: <52DEA04F.6030002@gmail.com>
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.
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.)
--
Colin Watson [cjwatson@ubuntu.com]
next prev parent reply other threads:[~2014-01-21 23:30 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 [this message]
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=20140121232957.GA24596@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).