Received: by 10.213.65.68 with SMTP id h4csp1386231imn; Wed, 4 Apr 2018 18:47:11 -0700 (PDT) X-Google-Smtp-Source: AIpwx48T5ywWlF5BCuRWgan77JZGAfWEGvz9xRSiD8RH09Sw/gALywSXwzNOSYpnxVmfMvX77mKu X-Received: by 2002:a17:902:2983:: with SMTP id h3-v6mr21242854plb.80.1522892831890; Wed, 04 Apr 2018 18:47:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522892831; cv=none; d=google.com; s=arc-20160816; b=nByGroVmrkq7HAoLSkxyg488ksar5lRAHkMnuMJeQpnsaeY0DvZW1O1JMnNj0rG1wm YylBXrysCkfrx41sGC8nQqGBHJxbG63ud3foDfbuWLVBgwTWAqZh54loKOftj+2fJXAg jWsBu+C5efIVL9pArO3X9M+v1Z1ptU5+FwXMLjPa6otpF5Fr+WPg+DZ56JjQpoEfC3np ZNYfrJe/v+eJPo7bYXzZOGH3XpPEMnSNsLm79riTDhufGf7o4b0Tqf+clWRmsrGv4YUs BTYGQNbXIGnVvJo8cV07uXVPz/tUTsaB3DvafEgY/G3BMECoC+sDyfgr5wjjSGXbkHth 3U4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=WFdd6yu8rILwU8X53NQHaMYBaoz+ueWHkRNLmwTfNY0=; b=qw3qw7wp1oemC+ZnglsgH0B0rDyaHPQ80Ml2HU5rfUs/Imy6EQ1dC7FLMCE+QlNf8+ JmSuhzatl40vu3k9udJRLAYZ9gbWCdEZaLuRNKbXrl3rAIgNUvlvoKvVbhThXB5y36vk L8YCpv6RBD25xIIOaqnu0jzL4etwgkvcuufpXVhghKClZDJR9PS7V4T3mfc2jMvBJTyJ lnmF/XUKyM20JEJzMVe9J3z+jjBlUy67e1KTl5puqZIvBCsifS91/Vign4zW1aI0/zRX K2GJ6PmoLVD6LZ+3OpQF7M1wlY/GyGlAORNKRfJrk9sQ9uZkW3g2kafGky6MUwuDz6zf uiWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w2si4635768pgt.485.2018.04.04.18.46.57; Wed, 04 Apr 2018 18:47:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752821AbeDEBpp (ORCPT + 99 others); Wed, 4 Apr 2018 21:45:45 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:40593 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752652AbeDEBpn (ORCPT ); Wed, 4 Apr 2018 21:45:43 -0400 Received: from linux-l9pv.suse (124-11-22-254.static.tfn.net.tw [124.11.22.254]) by smtp.nue.novell.com with ESMTP (TLS encrypted); Thu, 05 Apr 2018 03:45:34 +0200 Date: Thu, 5 Apr 2018 09:45:21 +0800 From: joeyli To: Andy Lutomirski Cc: Greg Kroah-Hartman , "Theodore Y. Ts'o" , Matthew Garrett , Linus Torvalds , David Howells , Ard Biesheuvel , James Morris , Alan Cox , Linux Kernel Mailing List , Justin Forbes , linux-man , LSM List , Linux API , Kees Cook , linux-efi Subject: Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot) Message-ID: <20180405014521.GA7362@linux-l9pv.suse> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, On Wed, Apr 04, 2018 at 07:49:12AM -0700, Andy Lutomirski wrote: > Since this thread has devolved horribly, I'm going to propose a solution. ... > 6. There's a way to *decrease* the lockdown level below the configured > value. (This ability itself may be gated by a config option.) > Choices include a UEFI protected variable, an authenticated flag > passed by the bootloader, and even just some special flag in the boot > handoff protocol. It would be really quite useful for a user to be > able to ask their bootloader to reduce the lockdown level for the > purpose of a particular boot for debugging. I read the docs on The "mokutil --disable-validation" done a similar bahvior as above. Just it lets kernel to ignore the secure boot. > mokutil --disable-validation, and it's quite messy. Let's have a way > to do this that is mostly independent of the particular firmware in > use. > Why the disabl-validation is messy? The mokutil is shim specific but not dependent on particular firmware. > I can imagine a grub option that decreases lockdown level along with a > rule that grub will *not* load that option from its config, for > example. > The root can modify the grub config to decrease lockdown level in next boot without physcial accessing. The mokutil's interactive UI is used to deal with user to confirm the physcial accessing. Thanks Joey Lee