From: Theodore Ts'o <tytso@mit.edu>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Matthew Garrett <matthew.garrett@nebula.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"jwboyer@fedoraproject.org" <jwboyer@fedoraproject.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown
Date: Fri, 14 Mar 2014 19:18:32 -0400 [thread overview]
Message-ID: <20140314231832.GA653@thunk.org> (raw)
In-Reply-To: <20140314220840.29a12171@alan.etchedpixels.co.uk>
On Fri, Mar 14, 2014 at 10:08:40PM +0000, One Thousand Gnomes wrote:
> > Signed userspace is not a requirement, and therefore any solution that
> > relies on a signed initrd is inadequate. There are use cases that
> > require verification of the initrd and other levels. This isn't one of
> > them.
>
> The job of the kernel is to solve the general problem. There are lots of
> people who happen to care about verification beyond the kernel so it
> shouldn't be ignored. And they can do do things like load trusted SELinux
> rulesets even if you can't support it in your environment.
This is really a question about goals and trust models. Alan is
arguing that we should support trust models and goals which go far
beyond the goals and trust model of the UEFI Forum.
Matthew is, I think, trying to make the argument that his patches
fulfill the goals that are needed so we can boot Linux distribution
kernels on UEFI secure boot machines without worrying about Microsoft
deciding to revoke keys so that Red Hat or SuSE will no longer be able
to be bootable on desktops that are certified for Windows 8. And
while we might want to improve the framework to support other trust
models later on, supporting distro kernels on Windows 8 certified PC's
is important enough that we should let these patches into mainline.
Is that a fair summary of the two viewpoints?
Personally, I think that we are fortunate that Windows 8 has been
enough of a train wreck that huge numbers of users have been taking
Windows 8 systems and upgrading them to Windows 7, and hence the need
for Distro kernels that can boot on fully locked down Windows 8 PC's.
But at some point, whether it is a few years or a decade later (if
Windows 7 lives on as long as XP :-), Windows 7 will be EOL'ed, and
even before that, UEFI secure boot will be enabled by default.
Right now, even though Lenovo laptops are shipping with Windows
8. UEFI secure boot is not made mandatory (although it is on enough to
brick the laptop when it runs into bugs wwith the UEFI BIOS code,
sigh). But sooner or later, UEFI secure boot will be on by default,
and then if Linux distros don't have kernels where the installer can
be run without needing to twiddle BIOS settings, it might make it
harder for the "Year of the Desktop" to come about.
So as far as the narrow question of whether we should accept these
patches, I think it's a good thing. Personally, I'm always going to
be disabling UEFI secure boot (even if it doesn't brick my laptop),
because for me, the security guarantees it provides isn't worth it.
But there will be people who want to be able to install Linux on
Windows 8 certified PC's without tweaking BIOS settings, so merging
the UEFI secure boot is a good thing, so long as those of use who
don't want to have anything to do with UEFI secure boot can disable
it.
Regards,
- Ted
next prev parent reply other threads:[~2014-03-14 23:18 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 20:11 Trusted kernel patchset for Secure Boot lockdown Matthew Garrett
2014-02-26 20:11 ` [PATCH 01/12] Add support for indicating that the booted kernel is externally trusted Matthew Garrett
[not found] ` <1393445473-15068-2-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2014-02-27 19:02 ` Kees Cook
2014-03-31 14:49 ` Pavel Machek
2014-02-26 20:11 ` [PATCH 03/12] PCI: Lock down BAR access when trusted_kernel is true Matthew Garrett
2014-02-26 20:11 ` [PATCH 04/12] x86: Lock down IO port " Matthew Garrett
2014-02-26 20:11 ` [PATCH 05/12] Restrict /dev/mem and /dev/kmem " Matthew Garrett
2014-02-26 20:11 ` [PATCH 06/12] acpi: Limit access to custom_method if " Matthew Garrett
2014-02-26 20:11 ` [PATCH 07/12] acpi: Ignore acpi_rsdp kernel parameter when " Matthew Garrett
2014-02-26 20:11 ` [PATCH 08/12] kexec: Disable at runtime if " Matthew Garrett
2014-02-26 20:11 ` [PATCH 10/12] x86: Restrict MSR access when " Matthew Garrett
2014-02-26 20:11 ` [PATCH 11/12] asus-wmi: Restrict debugfs interface " Matthew Garrett
[not found] ` <1393445473-15068-1-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2014-02-26 20:11 ` [PATCH 02/12] Enforce module signatures when trusted kernel is enabled Matthew Garrett
2014-02-26 20:11 ` [PATCH 09/12] uswsusp: Disable when trusted_kernel is true Matthew Garrett
2014-03-31 14:49 ` Pavel Machek
2014-02-26 20:11 ` [PATCH 12/12] Add option to automatically set trusted_kernel when in Secure Boot mode Matthew Garrett
[not found] ` <1393445473-15068-13-git-send-email-matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
2014-02-26 22:41 ` One Thousand Gnomes
2014-02-26 22:47 ` H. Peter Anvin
2014-02-26 22:48 ` Matthew Garrett
2014-02-27 18:48 ` Kees Cook
2014-02-27 18:04 ` Trusted kernel patchset for Secure Boot lockdown Josh Boyer
2014-02-27 19:07 ` Greg KH
[not found] ` <20140227190710.GA4755-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-02-27 19:11 ` Josh Boyer
2014-02-28 12:50 ` Josh Boyer
2014-02-28 3:03 ` James Morris
[not found] ` <alpine.LRH.2.02.1402281402090.26521-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2014-02-28 4:52 ` Matthew Garrett
2014-03-13 5:01 ` Matthew Garrett
2014-03-13 6:22 ` Kees Cook
2014-03-13 9:33 ` James Morris
2014-03-13 10:12 ` One Thousand Gnomes
[not found] ` <20140313101235.753c3ec0-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-13 15:54 ` H. Peter Anvin
2014-03-13 15:59 ` Matthew Garrett
2014-03-13 21:24 ` One Thousand Gnomes
2014-03-13 21:28 ` H. Peter Anvin
[not found] ` <532222E1.2020405-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2014-03-13 21:32 ` Matthew Garrett
[not found] ` <20140313212450.67f1de8e-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-13 21:30 ` Matthew Garrett
2014-03-13 23:21 ` One Thousand Gnomes
[not found] ` <20140313232140.03bdaac3-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-14 1:57 ` Matthew Garrett
[not found] ` <1394762250.6416.24.camel-+5W/JHIUVxg@public.gmane.org>
2014-03-14 12:22 ` One Thousand Gnomes
[not found] ` <20140314122231.17b9ca8a-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-14 12:51 ` Matthew Garrett
2014-03-14 15:23 ` Kees Cook
2014-03-14 15:46 ` Matthew Garrett
2014-03-14 15:54 ` Kees Cook
[not found] ` <CAGXu5j+3vVKhFPOsArYddA+QqhvVUunj8eYOF799rDv=3MGtyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-14 15:58 ` Matthew Garrett
[not found] ` <CAGXu5jLZcWh5WD0L8s3Q-GXdXCMnA57qtjfdFfQbv0fxYcuCTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-14 16:28 ` One Thousand Gnomes
2014-03-14 17:06 ` One Thousand Gnomes
2014-03-14 18:11 ` Matthew Garrett
[not found] ` <1394820664.26846.18.camel-OCPKQ0O/skbnpfJQjCtNlyaZ0x2G8ZQoAL8bYrjMMd8@public.gmane.org>
2014-03-14 19:24 ` Matthew Garrett
2014-03-14 20:37 ` David Lang
2014-03-14 20:43 ` Matthew Garrett
2014-03-14 21:58 ` One Thousand Gnomes
[not found] ` <20140314215854.50ec186a-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-14 22:04 ` Matthew Garrett
2014-03-14 21:48 ` One Thousand Gnomes
2014-03-14 21:56 ` Matthew Garrett
2014-03-14 22:08 ` One Thousand Gnomes
[not found] ` <20140314220840.29a12171-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-14 22:15 ` Matthew Garrett
2014-03-14 22:31 ` One Thousand Gnomes
2014-03-14 22:52 ` Matthew Garrett
[not found] ` <20140314223150.0b49723e-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-19 19:50 ` Kees Cook
2014-03-14 23:18 ` Theodore Ts'o [this message]
2014-03-15 0:15 ` One Thousand Gnomes
[not found] ` <20140314231832.GA653-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-03-19 17:49 ` Florian Weimer
2014-03-19 20:16 ` Kees Cook
[not found] ` <CAGXu5j+JXy4EbHxu+8twWo=3gqyLJ6hZGPbgsdf3t8YhUA-bWw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-20 14:47 ` One Thousand Gnomes
2014-03-20 14:55 ` tytso
[not found] ` <20140320145507.GB20618-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2014-03-20 17:12 ` Matthew Garrett
2014-03-20 18:13 ` One Thousand Gnomes
2014-03-13 21:26 ` One Thousand Gnomes
[not found] ` <20140313212647.7412aadf-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org>
2014-03-13 21:31 ` Matthew Garrett
2014-02-26 21:11 ` Kees Cook
[not found] ` <CAGXu5j+b49grru-=DTRC0wx5LTOHN_jKL0Q++uW0Mzy+BxDf4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-26 22:21 ` One Thousand Gnomes
2014-02-27 9:54 ` Alon Ziv
2014-03-19 17:42 ` Florian Weimer
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=20140314231832.GA653@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=jwboyer@fedoraproject.org \
--cc=keescook@chromium.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthew.garrett@nebula.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;
as well as URLs for NNTP newsgroup(s).