Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758113AbcK3Qv3 (ORCPT ); Wed, 30 Nov 2016 11:51:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42346 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753898AbcK3QvV (ORCPT ); Wed, 30 Nov 2016 11:51:21 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20161123104757.GE24624@leverpostej> References: <20161123104757.GE24624@leverpostej> <147986054870.13790.8640536414645705863.stgit@warthog.procyon.org.uk> <147986057768.13790.3027173260868896792.stgit@warthog.procyon.org.uk> To: Mark Rutland 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 Subject: Re: [PATCH 4/6] efi: Get the secure boot status [ver #2] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31766.1480524678.1@warthog.procyon.org.uk> Date: Wed, 30 Nov 2016 16:51:18 +0000 Message-ID: <31767.1480524678@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 30 Nov 2016 16:51:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1110 Lines: 27 Mark Rutland 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