mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: dhowells@redhat.com, lukas@wunner.de, linux-efi@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org, Matthew Garrett <mjg59@coreos.com>
Subject: Re: [PATCH 4/6] efi: Get the secure boot status [ver #2]
Date: Wed, 30 Nov 2016 16:51:18 +0000	[thread overview]
Message-ID: <31767.1480524678@warthog.procyon.org.uk> (raw)
In-Reply-To: <20161123104757.GE24624@leverpostej>

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

> > +	boot_params->secure_boot = (efi_get_secureboot(sys_table) == 1);
> 
> In the arm stub's efi_entry(), we fail-safe, and assume secure boot for any
> non-zero status (including errors). e.g. 

Okay, given what Matthew said:

	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.

I think I have to assume the default to be that secure boot is *not* enabled
in the case of one of the variables we need to check is not being present.

As for getting other errors, I think we have to assume a buggy BIOS.  In this
case, I would also go with assuming we're not in secure boot.

Another possibility is to punt the decision and make it compile-time
configurable.

David

  parent reply	other threads:[~2016-11-30 16:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23  0:22 [PATCH 0/6] efi: Pass secure boot mode to kernel " David Howells
2016-11-23  0:22 ` [PATCH 1/6] x86/efi: Allow invocation of arbitrary runtime services " David Howells
2016-11-23  0:22 ` [PATCH 2/6] arm/efi: " David Howells
2016-11-23 10:27   ` Mark Rutland
2016-11-23 11:46   ` David Howells
2016-11-23 13:38     ` Mark Rutland
2016-11-23  0:22 ` [PATCH 3/6] efi: Add SHIM and image security database GUID definitions " David Howells
2016-11-23  0:22 ` [PATCH 4/6] efi: Get the secure boot status " David Howells
2016-11-23  9:31   ` Lukas Wunner
2016-11-23  9:53   ` David Howells
2016-11-23 10:10     ` Lukas Wunner
2016-11-23 10:47   ` Mark Rutland
2016-11-23 11:25   ` David Howells
2016-11-23 13:42     ` Mark Rutland
2016-11-23 14:13     ` David Howells
2016-11-23 14:24       ` Mark Rutland
2016-11-23 14:55       ` David Howells
2016-11-29 18:11         ` Matthew Garrett
2016-11-30 16:51   ` David Howells [this message]
2016-11-23  0:23 ` [PATCH 5/6] efi: Disable secure boot if shim is in insecure mode " David Howells
2016-11-23 13:38   ` Mark Rutland
2016-11-23  0:23 ` [PATCH 6/6] efi: Add EFI_SECURE_BOOT bit " David Howells
2016-11-23  9:27   ` Lukas Wunner
2016-11-23 10:07   ` David Howells
2016-11-23 10:09   ` David Howells
2016-11-23  9:34 ` [PATCH 2/6] arm/efi: Allow invocation of arbitrary runtime services " David Howells
2016-11-23 10:35   ` Ard Biesheuvel
2016-11-23 11:51   ` David Howells

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=31767.1480524678@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mark.rutland@arm.com \
    --cc=mjg59@coreos.com \
    /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

all inboxes | Powered by JetHome®