From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751326AbdEaNeG convert rfc822-to-8bit (ORCPT ); Wed, 31 May 2017 09:34:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751292AbdEaNdz (ORCPT ); Wed, 31 May 2017 09:33:55 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7907785540 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dhowells@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7907785540 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: <149563711758.9419.11406612723056598045.stgit@warthog.procyon.org.uk> <21606.1496222635@warthog.procyon.org.uk> To: Ard Biesheuvel Cc: dhowells@redhat.com, Matthew Garrett , linux-security-module , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 0/5] security, efi: Set lockdown if in secure boot mode MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <378.1496237632.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Wed, 31 May 2017 14:33:52 +0100 Message-ID: <379.1496237632@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, 31 May 2017 13:33:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ard Biesheuvel wrote: > No, I am fine with keeping this as a single series. I don't want > anything under drivers/efi to imply policy regarding lockdown. Kernel > lockdown should be a feature that lives somewhere else, and which > contains a CONFIG_ option that implies 'lockdown is enabled by default > when UEFI secure boot is detected.' The code that gets added to > drivers/efi should only concern itself with establishing whether > secure boot is in effect or not (and can hence be enabled > unconditionally) > ... > So what I would prefer is to separate this from the EFI code, In that case I don't know where to connect the UEFI secure boot with the lockdown code. I was under the impression that you wanted the switch-statement that I had in x86 setup.c moved to the efi code (as I've done in patch 1). Was I wrong in that assessment and that you actually wanted it, say, in security? I don't think that the non-EFI core code should know about UEFI secure boot mode. Either the arch needs to implement the connection or the EFI code needs to implement it. In the former is preferred, I should drop patch 1. > ... and perhaps print something like > > lockdown: Kernel lockdown policy in effect due to xxx I'm okay with printing that instead. > and print a subsequent line for every lockdown feature that is enabled, e.g., > > lockdown: disabling MSRs > lockdown: disabling hibernate support That could add a lot of lines to the boot output:-/ David