From: Matthew Garrett <matthew.garrett@nebula.com>
To: Kees Cook <keescook@chromium.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] x86: Lock down MSR writing in secure boot
Date: Fri, 8 Feb 2013 20:34:31 +0000 [thread overview]
Message-ID: <1360355671.18083.18.camel@x230.lan> (raw)
In-Reply-To: <CAGXu5jLAufTRm=sDST0br_WEkn4o0Hpjv2jDP2Na=cCvuM+MGg@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1039 bytes --]
On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote:
> Maybe a capability isn't the right way to go, I'm not sure. I'll leave
> that to Matthew. Whatever the flag, it should be an immutable state of
> the boot. Though, it probably makes sense as a cap just so that
> non-secure-boot systems can still remove it from containers, etc.
There was interest in ensuring that this wasn't something special-cased
to UEFI Secure Boot, so using a capability seemed like the most
straightforward way - it's fundamentally a restriction on what an
otherwise privileged user is able to do, so it seemed like it fit the
model. But I'm not wed to it in the slightest, and in fact it causes
problems for some userspace (anything that drops all capabilities
suddenly finds itself unable to do something that it expects to be able
to do), so if anyone has any suggestions for a better approach…
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
next prev parent reply other threads:[~2013-02-08 20:52 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-08 19:12 [PATCH] x86: Lock down MSR writing in secure boot Kees Cook
2013-02-08 19:17 ` H. Peter Anvin
2013-02-08 19:18 ` Kees Cook
2013-02-08 19:42 ` H. Peter Anvin
2013-02-08 20:14 ` Kees Cook
2013-02-08 20:18 ` H. Peter Anvin
2013-02-08 20:28 ` Kees Cook
2013-02-08 20:34 ` Matthew Garrett [this message]
2013-02-08 21:02 ` Kees Cook
2013-02-08 21:07 ` Matthew Garrett
2013-02-08 21:14 ` Josh Boyer
2013-02-08 23:09 ` Andy Lutomirski
2013-02-08 22:30 ` H. Peter Anvin
2013-02-08 23:06 ` Borislav Petkov
2013-02-08 23:26 ` Matthew Garrett
2013-02-09 1:22 ` H. Peter Anvin
2013-02-09 1:29 ` Matthew Garrett
2013-02-09 6:45 ` Kees Cook
2013-02-09 9:29 ` Borislav Petkov
2013-02-09 15:10 ` Kees Cook
2013-02-09 15:11 ` Matthew Garrett
2013-02-13 0:48 ` H. Peter Anvin
2013-02-13 5:39 ` Matthew Garrett
2013-02-13 6:12 ` H. Peter Anvin
2013-02-13 6:27 ` Matthew Garrett
2013-02-13 6:33 ` H. Peter Anvin
2013-02-13 6:41 ` Matthew Garrett
2013-02-13 17:20 ` H. Peter Anvin
2013-02-13 17:26 ` Matthew Garrett
2013-02-13 17:51 ` Casey Schaufler
2013-02-13 17:56 ` Matthew Garrett
2013-02-13 18:44 ` H. Peter Anvin
2013-02-13 18:51 ` Matthew Garrett
2013-02-13 22:26 ` H. Peter Anvin
2013-02-13 22:58 ` Casey Schaufler
2013-02-14 0:25 ` H. Peter Anvin
2013-02-14 0:44 ` Casey Schaufler
2013-02-14 1:04 ` Matthew Garrett
2013-02-14 1:08 ` H. Peter Anvin
2013-02-14 2:46 ` Matthew Garrett
2013-02-14 1:34 ` Casey Schaufler
2013-02-13 8:27 ` Paolo Bonzini
2013-02-13 17:21 ` H. Peter Anvin
2013-02-13 17:22 ` H. Peter Anvin
2013-02-13 19:55 ` Paolo Bonzini
2013-02-13 22:24 ` H. Peter Anvin
2013-02-08 19:17 ` Matthew Garrett
2013-02-08 19:21 ` Kees Cook
2013-02-08 19:27 ` Matthew Garrett
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=1360355671.18083.18.camel@x230.lan \
--to=matthew.garrett@nebula.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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).