From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752129AbdAaS7h (ORCPT ); Tue, 31 Jan 2017 13:59:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38792 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751498AbdAaS72 (ORCPT ); Tue, 31 Jan 2017 13:59:28 -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: References: <148587558696.4026.16034622623568539004.stgit@warthog.procyon.org.uk> <148587564847.4026.5759345672956585977.stgit@warthog.procyon.org.uk> To: Ard Biesheuvel , James Bottomley Cc: dhowells@redhat.com, Matt Fleming , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-security-module , keyrings@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10453.1485889162.1@warthog.procyon.org.uk> Date: Tue, 31 Jan 2017 18:59:22 +0000 Message-ID: <10454.1485889162@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 31 Jan 2017 18:59:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ard Biesheuvel wrote: > > UEFI-2.6 adds a new variable, DeployedMode. If it exists, this must be 1 > > if we're to engage lockdown mode. > > > > Reported-by: James Bottomley > > Signed-off-by: David Howells > > Interestingly, the string 'DeployedMode' appears zero times in the > EDK2 codebase, so I wonder if it makes any sense to merge this now. > The string 'AuditMode' does appear once, but in a comment It's in the standard, so shouldn't we check for it? > In any case, the logic is not entirely correct either: apologies if it > was me who caused any confusion here, but it seems DeployedMode could > legally be 0 or 1 while secure boot is in fact enabled. It is actually > AuditMode that should be taken into account here, i.e., if AuditMode > == 1, the firmware ignores invalid or missing signatures. If > SecureBoot == 0x1, SetupMode == 0x0 and AuditMode == 0x0 (or > non-existent), signature verification is performed regardless of the > value (or existence) of DeployedMode. > > So I propose to respin this patch to treat AuditMode == 0x1 as 'secure > boot disabled', and ignore if it is missing. Ummm... This might conflict what said: | Since you seem to be using this to mean "is the platform locked down?", | this looks to be no longer complete in the UEFI 2.6 world. If | DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can | remove the platform key by writing 1 to AuditMode and gain control of | the secure variables. The lock down state becomes DeployedMode == 1, | SecureBoot == 1 and SetupMode == 0 | | See the diagram on page 1817 | | http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf Looking again at that diagram, should I be checking all four variables (SecureBoot, SetupMode, DeployedMode and AuditMode)? And/or should I treat audit mode differently to deployed mode? Further, there doesn't seem to be a state in which SecureBoot is shown as being 1. David