Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933757AbcK2SL1 (ORCPT ); Tue, 29 Nov 2016 13:11:27 -0500 Received: from mail-ua0-f174.google.com ([209.85.217.174]:34879 "EHLO mail-ua0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933709AbcK2SLT (ORCPT ); Tue, 29 Nov 2016 13:11:19 -0500 MIME-Version: 1.0 In-Reply-To: <2794.1479912933@warthog.procyon.org.uk> References: <20161123134219.GH24624@leverpostej> <20161123104757.GE24624@leverpostej> <147986054870.13790.8640536414645705863.stgit@warthog.procyon.org.uk> <147986057768.13790.3027173260868896792.stgit@warthog.procyon.org.uk> <18007.1479900357@warthog.procyon.org.uk> <31974.1479910408@warthog.procyon.org.uk> <20161123142440.GJ24624@leverpostej> <2794.1479912933@warthog.procyon.org.uk> From: Matthew Garrett Date: Tue, 29 Nov 2016 10:11:18 -0800 Message-ID: Subject: Re: [PATCH 4/6] efi: Get the secure boot status [ver #2] To: David Howells Cc: Mark Rutland , lukas@wunner.de, linux-efi@vger.kernel.org, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1037 Lines: 21 On Wed, Nov 23, 2016 at 6:55 AM, David Howells wrote: > Mark Rutland 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.