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:   Wed, 23 Nov 2016 14:13:28 +0000
From:   David Howells <dhowells@...hat.com>
To:     Mark Rutland <mark.rutland@....com>
Cc:     dhowells@...hat.com, lukas@...ner.de, linux-efi@...r.kernel.org,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] efi: Get the secure boot status [ver #2]

Mark Rutland <mark.rutland@....com> wrote:

> > > 	if (secure_boot < 0)
> > > 		pr_efi_err(sys_table,
> > > 			"could not determine UEFI Secure Boot status.\n");
> > 
> > In which case, should this be moved into efi_get_secureboot() and it return a
> > bool?
> 
> That would make sense to me, provided we're only likely to call that
> once (and only log once).
> 
> I guess it would also make sense to change the latter case to soemthing
> like:
> 	
> 	Could not determine UEFI Secure Boot status. Assuming enabled.
> 
> ... so as to make it clear what the effect is.

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.

David