linux-kernel - Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKv+Gu_gy6575axL6M64OSo33ZM2dnbs7cajqJRd8VtbjAXCTw@mail.gmail.com>
Date:   Wed, 1 Feb 2017 10:15:02 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     David Howells <dhowells@...hat.com>
Cc:     James Bottomley <James.Bottomley@...senpartnership.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        keyrings@...r.kernel.org,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7]

On 31 January 2017 at 18:59, David Howells <dhowells@...hat.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@...aro.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@...senPartnership.com>
>> > Signed-off-by: David Howells <dhowells@...hat.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.