From: Simon McVittie <simon.mcvittie@collabora.co.uk>
To: Kees Cook <keescook@chromium.org>,
Matthew Garrett <matthew.garrett@nebula.com>
Cc: "gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"james.l.morris@oracle.com" <james.l.morris@oracle.com>,
"serge@hallyn.com" <serge@hallyn.com>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>
Subject: Re: Trusted kernel patchset
Date: Tue, 17 Mar 2015 20:22:04 +0000 [thread overview]
Message-ID: <55088CEC.2010109@collabora.co.uk> (raw)
In-Reply-To: <CAGXu5jLKnBXFh6HgtfXuY=hpMEzi9siNeO5uh8gaeEzgOgDayg@mail.gmail.com>
On 16/03/15 21:29, Kees Cook wrote:
> I really think "trusted" is the right term here. It's about as
> accurate as possible for what this flag means.
A subtlety that might make this clearer: there isn't really such a thing
as "trusted" in isolation, only "trusted by..." a specific other party;
and in this case, as far as I can see, the intended meaning is that
lower layers (firmware and/or bootloader) have been configured to trust
this particular kernel.
It doesn't mean "user-space can trust me not to do bad things", because
any kernel, malicious or otherwise, could indeed easily claim that; and
if it is lying, what is user-space going to do about it anyway? Rather,
it means "the firmware is trusting me not to do things it would consider
bad".
I assume the intention isn't that it will make privileged bits of
userland be more careful to avoid breaking this trust assumption,
because the point of this patchset seems to be to make it impossible
(modulo bugs) for userland to do that.
Is the intention instead that it will make privileged bits of userland
more careful to avoid breaking the trust chain in ways that would "fail
safe" by refusing to boot?
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
next prev parent reply other threads:[~2015-03-17 20:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 21:38 Trusted kernel patchset Matthew Garrett
2015-03-13 21:38 ` [PATCH 01/12] Add support for indicating that the booted kernel is externally trusted Matthew Garrett
2015-03-13 21:38 ` [PATCH 02/12] Enforce module signatures when trusted kernel is enabled Matthew Garrett
2015-03-13 21:38 ` [PATCH 03/12] PCI: Lock down register access when trusted_kernel is true Matthew Garrett
2015-03-13 21:38 ` [PATCH 04/12] x86: Lock down IO port " Matthew Garrett
2015-03-13 21:38 ` [PATCH 05/12] Restrict /dev/mem and /dev/kmem " Matthew Garrett
2015-03-13 21:38 ` [PATCH 06/12] acpi: Limit access to custom_method if " Matthew Garrett
2015-03-13 21:38 ` [PATCH 07/12] acpi: Ignore acpi_rsdp kernel parameter when " Matthew Garrett
2015-03-13 21:38 ` [PATCH 08/12] kexec: Disable loading of unverified images Matthew Garrett
2015-03-13 21:38 ` [PATCH 09/12] uswsusp: Disable when trusted_kernel is true Matthew Garrett
2015-03-16 21:36 ` Kees Cook
2015-03-16 21:40 ` Matthew Garrett
2015-03-13 21:38 ` [PATCH 10/12] x86: Restrict MSR access " Matthew Garrett
2015-03-13 21:38 ` [PATCH 11/12] asus-wmi: Restrict debugfs interface " Matthew Garrett
2015-03-13 21:38 ` [PATCH 12/12] Add option to automatically set trusted_kernel when in Secure Boot mode Matthew Garrett
2015-04-22 11:36 ` Dan Carpenter
2015-03-15 1:53 ` Trusted kernel patchset Matthew Garrett
2015-03-16 14:45 ` One Thousand Gnomes
2015-03-16 18:15 ` Matthew Garrett
2015-03-16 20:07 ` One Thousand Gnomes
2015-03-16 20:35 ` David Lang
2015-03-16 20:57 ` One Thousand Gnomes
2015-03-16 21:11 ` Matthew Garrett
2015-03-16 21:29 ` Kees Cook
2015-03-17 17:48 ` One Thousand Gnomes
2015-03-17 20:22 ` Simon McVittie [this message]
2015-03-17 20:42 ` Matthew Garrett
2015-03-18 11:34 ` Simon McVittie
2015-03-16 21:54 ` Jiri Kosina
2015-03-18 13:24 ` joeyli
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=55088CEC.2010109@collabora.co.uk \
--to=simon.mcvittie@collabora.co.uk \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=hpa@zytor.com \
--cc=james.l.morris@oracle.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
--cc=serge@hallyn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox