From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: David Howells <dhowells@redhat.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
keyrings@vger.kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7]
Date: Wed, 1 Feb 2017 10:15:02 +0000 [thread overview]
Message-ID: <CAKv+Gu_gy6575axL6M64OSo33ZM2dnbs7cajqJRd8VtbjAXCTw@mail.gmail.com> (raw)
In-Reply-To: <10454.1485889162@warthog.procyon.org.uk>
On 31 January 2017 at 18:59, David Howells <dhowells@redhat.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> > UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1
>> > if we're to engage lockdown mode.
>> >
>> > Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>> > Signed-off-by: David Howells <dhowells@redhat.com>
>>
>> Interestingly, the string 'DeployedMode' appears zero times in the
>> EDK2 codebase, so I wonder if it makes any sense to merge this now.
>> The string 'AuditMode' does appear once, but in a comment
>
> It's in the standard, so shouldn't we check for it?
>
>> In any case, the logic is not entirely correct either: apologies if it
>> was me who caused any confusion here, but it seems DeployedMode could
>> legally be 0 or 1 while secure boot is in fact enabled. It is actually
>> AuditMode that should be taken into account here, i.e., if AuditMode
>> == 1, the firmware ignores invalid or missing signatures. If
>> SecureBoot == 0x1, SetupMode == 0x0 and AuditMode == 0x0 (or
>> non-existent), signature verification is performed regardless of the
>> value (or existence) of DeployedMode.
>>
>> So I propose to respin this patch to treat AuditMode == 0x1 as 'secure
>> boot disabled', and ignore if it is missing.
>
> Ummm... This might conflict what said:
>
> | Since you seem to be using this to mean "is the platform locked down?",
> | this looks to be no longer complete in the UEFI 2.6 world. If
> | DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can
> | remove the platform key by writing 1 to AuditMode and gain control of
> | the secure variables. The lock down state becomes DeployedMode == 1,
> | SecureBoot == 1 and SetupMode == 0
> |
> | See the diagram on page 1817
> |
> | http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
>
> Looking again at that diagram, should I be checking all four variables
> (SecureBoot, SetupMode, DeployedMode and AuditMode)? And/or should I treat
> audit mode differently to deployed mode?
>
Well, we are trying to decide whether the system is locked down or
not. AuditMode is only writable before ExitBootServices(), and when
AuditMode == 0, signature verification occurs as usual, regardless of
the value of DeployedMode. Whether someone could turn on AuditMode on
the *next* boot does not sound that relevant to me, since someone
could also re-enter SetupMode in the same way.
So this patch should take AuditMode into account, but not DeployedMode, i.e.,
SecureBoot == 0x1
SetupMode == 0x0
AuditMode == 0x0 (or non-existent)
implies a locked down state.
> Further, there doesn't seem to be a state in which SecureBoot is shown as
> being 1.
>
Yes, that is sloppy. But the fact that EDK2, being the v2.6 reference,
does not implement any of this *at all* is much more worrying to me,
given that UDK2017 based firmware will certainly turn up in production
systems.
next prev parent reply other threads:[~2017-02-01 10:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 15:13 [PATCH 0/7] efi: Pass secure boot mode to kernel [ver #7] David Howells
2017-01-31 15:13 ` [PATCH 1/7] x86/efi: Allow invocation of arbitrary runtime services " David Howells
2017-01-31 15:13 ` [PATCH 2/7] arm/efi: " David Howells
2017-01-31 15:13 ` [PATCH 3/7] efi: Add SHIM and image security database GUID definitions " David Howells
2017-01-31 15:13 ` [PATCH 4/7] efi: Get the secure boot status " David Howells
2017-01-31 17:37 ` kbuild test robot
2017-01-31 18:04 ` kbuild test robot
2017-02-02 21:34 ` Matt Fleming
2017-01-31 15:13 ` [PATCH 5/7] efi: Disable secure boot if shim is in insecure mode " David Howells
2017-01-31 15:14 ` [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 " David Howells
2017-01-31 18:19 ` Ard Biesheuvel
2017-01-31 18:59 ` David Howells
2017-02-01 10:15 ` Ard Biesheuvel [this message]
2017-02-01 12:33 ` David Howells
2017-02-01 14:44 ` Ard Biesheuvel
2017-02-01 15:00 ` David Howells
2017-02-01 15:02 ` Ard Biesheuvel
2017-02-02 21:36 ` Matt Fleming
2017-02-02 21:45 ` Ard Biesheuvel
2017-02-01 10:02 ` David Howells
2017-01-31 15:14 ` [PATCH 7/7] efi: Print the secure boot status in x86 setup_arch() " David Howells
2017-02-03 16:07 ` Ard Biesheuvel
2017-02-03 16:21 ` David Howells
2017-02-03 16:23 ` Ard Biesheuvel
2017-02-03 16:27 ` David Howells
2017-02-03 16:29 ` David Howells
2017-02-03 16:29 ` Ard Biesheuvel
2017-02-03 17:00 ` Ard Biesheuvel
2017-02-03 17:19 ` David Howells
2017-01-31 16:45 ` [PATCH 0/7] efi: Pass secure boot mode to kernel " Ard Biesheuvel
2017-01-31 17:04 ` David Howells
2017-01-31 18:20 ` Ard Biesheuvel
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+Gu_gy6575axL6M64OSo33ZM2dnbs7cajqJRd8VtbjAXCTw@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
/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).