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:24:40 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     David Howells <dhowells@...hat.com>
Cc:     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]

On Wed, Nov 23, 2016 at 02:13:28PM +0000, David Howells wrote:
> 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.

Ok.

IIUC, that x86 patch was never upstream, so is there any need to follow
that example? Was there a rationale for that, or can we simply follow
the upstream ARM example?

Perhaps it's best to ask Matthew?

Thanks,
Mark.