Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754534AbcKUNO5 (ORCPT ); Mon, 21 Nov 2016 08:14:57 -0500 Received: from mail-io0-f181.google.com ([209.85.223.181]:33217 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754185AbcKUNOy (ORCPT ); Mon, 21 Nov 2016 08:14:54 -0500 MIME-Version: 1.0 In-Reply-To: <5701.1479732075@warthog.procyon.org.uk> References: <147933283664.19316.12454053022687659937.stgit@warthog.procyon.org.uk> <147933285147.19316.11046583275861569558.stgit@warthog.procyon.org.uk> <20161117123731.GA11573@wunner.de> <29779.1479728545@warthog.procyon.org.uk> <5701.1479732075@warthog.procyon.org.uk> From: Ard Biesheuvel Date: Mon, 21 Nov 2016 13:14:52 +0000 Message-ID: Subject: Re: [PATCH 02/16] efi: Get the secure boot status To: David Howells Cc: Linn Crosetto , Lukas Wunner , keyrings@vger.kernel.org, Matthew Garrett , linux-security-module , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" 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: 1247 Lines: 32 On 21 November 2016 at 12:41, David Howells wrote: > Ard Biesheuvel wrote: > >> > Looking in efi_get_secureboot(), is there a reason: >> > >> > efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID; >> > >> > isn't static const? >> > >> >> Not a good one, no. It used to be static const, but for some reason, >> commit 30d7bf034c03 ("efi/arm64: Check SetupMode when determining >> Secure Boot status") removed the static and the const (and I reviewed >> it and did not complain AFAIR) >> I'll gladly take a patch that reinstates that, though. > > Also, is there a reason that: > > typedef efi_status_t efi_get_variable_t (efi_char16_t *name, efi_guid_t *vendor, u32 *attr, > unsigned long *data_size, void *data); > > Doesn't have const name and vendor? > Yes, but not a good one either. Sadly, the prototypes in the UEFI spec completely ignore constness, and these definitions are intended to be identical to the ones in the spec. This also means, for instance, that most UEFI firmwares stores these kinds of GUIDs in read-write memory, which is a potential goldmine for hackers, given how GUIDs are UEFI's duct tape, i.e., keeping the world together.