From: Andy Lutomirski <luto@amacapital.net>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Trusted kernel patchset
Date: Wed, 7 May 2014 11:53:15 -0700 [thread overview]
Message-ID: <CALCETrULGiH=Afoqu8W06x=e2EQr6v7t10OSgYdxdu3df__pTQ@mail.gmail.com> (raw)
In-Reply-To: <20140507180315.GA926@srcf.ucam.org>
On Wed, May 7, 2014 at 11:03 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> (Posting as core rather than tech because I suspect this is more
> political than technical at this point)
>
> Most major distributions ship these. There is strong demand from Google,
> who want to use them in a use-case that has nothing to do with UEFI
> Secure Boot. Making a distinction between root and kernel security is a
> necessary part of securing a boot chain[1].
>
> Yet, after apparently gaining at least a rough consensus at LPC last
> year, we're now at the point where there's yet another suggestion for
> how to rewrite them but absolutely nobody showing any signs of being
> willing to do that work or any agreement from anyone in the security
> community that entirely reworking capabilities is either practical or
> desirable.
I am very interested in this, both from the POV of how capabilities do
and/or should work, and of what trusted boot should do.
There is a lot of very vocal opposition to any change in the way that
capabilities work, and I think that, at some point, it might be
helpful if enough people who think that capabilities can change
reached some kind of consensus so that something can be done.
That being said, capabilities are a giant mess, and it might be really
hard to fix them.
--Andy
prev parent reply other threads:[~2014-05-07 18:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 18:03 Matthew Garrett
2014-05-07 18:14 ` Josh Boyer
2014-05-07 18:53 ` Andy Lutomirski [this message]
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='CALCETrULGiH=Afoqu8W06x=e2EQr6v7t10OSgYdxdu3df__pTQ@mail.gmail.com' \
--to=luto@amacapital.net \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mjg59@srcf.ucam.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