Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753783AbcKRMKi (ORCPT ); Fri, 18 Nov 2016 07:10:38 -0500 Received: from mail-it0-f43.google.com ([209.85.214.43]:34998 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752941AbcKRMKe (ORCPT ); Fri, 18 Nov 2016 07:10:34 -0500 MIME-Version: 1.0 In-Reply-To: References: <147933283664.19316.12454053022687659937.stgit@warthog.procyon.org.uk> <147933287290.19316.3360403691390019935.stgit@warthog.procyon.org.uk> From: Ard Biesheuvel Date: Fri, 18 Nov 2016 12:10:32 +0000 Message-ID: Subject: Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit To: Josh Boyer Cc: David Howells , keyrings@vger.kernel.org, Matthew Garrett , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-security-module 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: 2196 Lines: 53 On 18 November 2016 at 11:58, Josh Boyer wrote: > On Thu, Nov 17, 2016 at 4:58 PM, Ard Biesheuvel > wrote: >> On 16 November 2016 at 21:47, David Howells wrote: >>> From: Josh Boyer >>> >>> UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit >>> for use with efi_enabled. >>> >>> Signed-off-by: Josh Boyer >>> Signed-off-by: David Howells >>> --- >>> >>> arch/x86/kernel/setup.c | 1 + >>> include/linux/efi.h | 1 + >>> 2 files changed, 2 insertions(+) >>> >>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c >>> index 9521acce8378..539f29587712 100644 >>> --- a/arch/x86/kernel/setup.c >>> +++ b/arch/x86/kernel/setup.c >>> @@ -1164,6 +1164,7 @@ void __init setup_arch(char **cmdline_p) >>> if (boot_params.secure_boot && >>> IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) { >>> lock_kernel_down(); >>> + set_bit(EFI_SECURE_BOOT, &efi.flags); >> >> Why is this x86 only? And why is this bit only set if > > Because it was initially written like 3 years ago before ARM even had > UEFI. Needs a refresh. > Ah ok. I missed that part. In any case, we have been working very hard over the past couple of years to move all the UEFI stuff out of arch/x86, except for the pieces that *really* belong there. For this series, that means that a fair share of the changes will need to be reworked and moved under drivers/firmware/efi. Note that that also means you cannot use L"" string literals anymore, since arm64's UEFI stub is linked into the kernel proper, and the wide character formats are incompatible between UEFI and the wide char handling that occurs under fs/. Please check the existing secureboot_enabled() function Lukas referred to as an example how to emit wide string literals instead. >> CONFIG_EFI_SECURE_BOOT_LOCK_DOWN is enabled? > > That part is new and something David added. Probably not necessary. > Regardless of anything else, think is is useful to have a EFI_xx flag that is always set when secure boot is enabled.