From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: David Howells <dhowells@redhat.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] security, efi: Set lockdown if in secure boot mode
Date: Wed, 31 May 2017 14:06:55 +0000 [thread overview]
Message-ID: <CAKv+Gu83jXn4WYV1EQ0ixTmHnM7mTmb_XNHwcMxuH2sizOnHKw@mail.gmail.com> (raw)
In-Reply-To: <379.1496237632@warthog.procyon.org.uk>
On 31 May 2017 at 13:33, David Howells <dhowells@redhat.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> No, I am fine with keeping this as a single series. I don't want
>> anything under drivers/efi to imply policy regarding lockdown. Kernel
>> lockdown should be a feature that lives somewhere else, and which
>> contains a CONFIG_ option that implies 'lockdown is enabled by default
>> when UEFI secure boot is detected.' The code that gets added to
>> drivers/efi should only concern itself with establishing whether
>> secure boot is in effect or not (and can hence be enabled
>> unconditionally)
>> ...
>> So what I would prefer is to separate this from the EFI code,
>
> In that case I don't know where to connect the UEFI secure boot with the
> lockdown code.
>
> I was under the impression that you wanted the switch-statement that I had in
> x86 setup.c moved to the efi code (as I've done in patch 1). Was I wrong in
> that assessment and that you actually wanted it, say, in security?
>
No, that patch, and the patch that sets the EFI_SECURE_BOOT flag are
perfectly fine. I just think it should be the lockdown code that
contains the efi_enabled(EFI_SECURE_BOOT) check. Note that linux/efi.h
does the right thing in case CONFIG_EFI is not defined.
> I don't think that the non-EFI core code should know about UEFI secure boot
> mode. Either the arch needs to implement the connection or the EFI code needs
> to implement it. In the former is preferred, I should drop patch 1.
>
>> ... and perhaps print something like
>>
>> lockdown: Kernel lockdown policy in effect due to xxx
>
> I'm okay with printing that instead.
>
>> and print a subsequent line for every lockdown feature that is enabled, e.g.,
>>
>> lockdown: disabling MSRs
>> lockdown: disabling hibernate support
>
> That could add a lot of lines to the boot output:-/
>
Why is that a bad thing?
next prev parent reply other threads:[~2017-05-31 14:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 14:45 [PATCH 0/5] security, efi: Set lockdown if in secure boot mode David Howells
2017-05-24 14:45 ` [PATCH 1/5] efi: Move the x86 secure boot switch to generic code David Howells
2017-05-26 7:59 ` joeyli
[not found] ` <149563711758.9419.11406612723056598045.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-05-24 14:45 ` [PATCH 2/5] efi: Add EFI_SECURE_BOOT bit David Howells
2017-05-26 8:06 ` joeyli
2017-05-24 14:45 ` [PATCH 3/5] Add the ability to lock down access to the running kernel image David Howells
[not found] ` <80bdc6c9-004b-800f-ffd0-4b5ebf8cdeba-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-05-25 6:53 ` David Howells
[not found] ` <19783.1495695202-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-05-25 18:18 ` Casey Schaufler
[not found] ` <fa6647c3-baff-d9e9-8ffe-89042b2a553d-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-05-26 12:43 ` David Howells
2017-05-26 17:08 ` joeyli
[not found] ` <149563714531.9419.16811189348445249219.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-05-24 15:36 ` Casey Schaufler
2017-05-26 8:16 ` joeyli
2017-05-24 14:45 ` [PATCH 4/5] efi: Lock down the kernel if booted in secure boot mode David Howells
2017-05-26 8:29 ` joeyli
2017-05-24 14:46 ` [PATCH 5/5] Add a sysrq option to exit " David Howells
2017-05-27 4:06 ` joeyli
[not found] ` <149563716341.9419.12043461651917925181.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-05-30 10:49 ` James Morris
2017-05-30 18:57 ` [PATCH 0/5] security, efi: Set lockdown if in " Ard Biesheuvel
[not found] ` <CAKv+Gu_5gUWwx7Sxgm8d03L4t4nF8dDe+AXqOqto4B7AVSZ9CA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-31 9:23 ` David Howells
[not found] ` <21606.1496222635-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-05-31 11:39 ` Ard Biesheuvel
2017-05-31 13:33 ` David Howells
2017-05-31 14:06 ` Ard Biesheuvel [this message]
[not found] ` <CAKv+Gu_vXASr=yDJ3MwT960eApqeWKEd-hqGoEyGsJKip7N+KQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-06 9:34 ` David Howells
[not found] ` <25009.1496741691-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-06-09 17:33 ` Ard Biesheuvel
2017-06-09 19:22 ` Kees Cook
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=CAKv+Gu83jXn4WYV1EQ0ixTmHnM7mTmb_XNHwcMxuH2sizOnHKw@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=dhowells@redhat.com \
--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).