linux-kernel - Re: [PATCH 4/6] efi: Get the secure boot status [ver #2]

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]

Date:   Tue, 29 Nov 2016 10:11:18 -0800
From:   Matthew Garrett <mjg59@...eos.com>
To:     David Howells <dhowells@...hat.com>
Cc:     Mark Rutland <mark.rutland@....com>, lukas@...ner.de,
        linux-efi@...r.kernel.org, linux-security-module@...r.kernel.org,
        keyrings@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/6] efi: Get the secure boot status [ver #2]

On Wed, Nov 23, 2016 at 6:55 AM, David Howells <dhowells@...hat.com> wrote:
> Mark Rutland <mark.rutland@....com> wrote:
>> > Actually, the two arches have a different interpretation on how to deal
>> > with an error.  Matthew Garrett's original x86 patch assumes that if we
>> > get an error when trying to read SecureBoot and SetupMode that we're *not*
>> > in secure mode, but ARM assumes the opposite.
>>
>> Ok.
>>
>> IIUC, that x86 patch was never upstream, so is there any need to follow
>> that example?
>
> Whilst that may be true, that doesn't mean a lot of people aren't using it.

A conforming implementation that supports secure boot should always
return those variables without error. If they're not present (which is
valid for x86 systems - many predate the feature) then assuming Secure
Boot is disabled is correct. The question of what to do in the event
of other errors is more open, but it wouldn't surprise me if there are
implementations that return non-spec errors for missing variables
under certain circumstances.