Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2680267imm; Sun, 5 Aug 2018 09:34:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcj5ma0CWea8Dulyzu/qz/Ngd7/oNS8K1eo5/CoMg1rY7cnyrM/KcX+/fYhGtt3g9yvFwx3 X-Received: by 2002:a17:902:6b0b:: with SMTP id o11-v6mr10837907plk.214.1533486891579; Sun, 05 Aug 2018 09:34:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533486891; cv=none; d=google.com; s=arc-20160816; b=a0cFvWyXz4GP6X+qXZCogA6Mc1o/9m9ZDcxncantr/1EuHex54syeHxp3Jt3wmxh64 L9UpP3ncqEzRMrtAtfsKavuuK8hWMq4+mAhzEO+XtTQombadYXHlxWmYjAKEGS8kbZ/m su/W+T9Cl9WE+sEm4pmYJS4CgS5wdDybZLbrBs4cuN35CGlU4ol4yXDRrSQK8Lt9lC16 r5rJf6sQ689i0D6z7vrvoFqWq+VJhSrP0x4yTaShvKbRUOw92Nj4FNRkB3BBkurx0Sa9 ceSByLYd93z3BRI1rQh0Hmii45s17a9C7p/bRCusCw6MHuhbviXJwNXneKStK96RPm21 PB+Q== 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=W6pANmx9gJRRQ1QCXvKzmx5PVi2Rjedw0vySRpRT5b4=; b=DYVFn0AGa4RodBXkD34eQ1PtJ4t5HNY6zoHybyXqHa/FJRPZcOb5qeBYb/L9fDhLxF fkJtkw+HlV5hS5ROH+ckynXgNOljjeb0ypvy0sJEyjdNn+2S9Vk2uDFq7t0uv9Kad7cV oIXPsag1/HNgCanRCwgTU8jtXMqgZPpZL2peFllvI2Lnl+05pFHTJi0U7Gafw/3AWp0e Yg+lrVoa/f+HC08ib3sUAjlRvobSLukKmSeDDOSA+4HYVHGwS/QFRMOy7i4QJf0oP73o BK2vy22fQMVsQdBnbN1Ud5jlr9h24kSDUBoyNKg7FDmwHEQMaSFi9WMn08Q7oyzH7ekF nuhg== 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 p3-v6si8291466plk.295.2018.08.05.09.34.09; Sun, 05 Aug 2018 09:34:51 -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 S1726447AbeHEShE (ORCPT + 99 others); Sun, 5 Aug 2018 14:37:04 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:45841 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726207AbeHEShE (ORCPT ); Sun, 5 Aug 2018 14:37:04 -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); Sun, 05 Aug 2018 18:31:46 +0200 Date: Mon, 6 Aug 2018 00:31:39 +0800 From: joeyli To: Ard Biesheuvel Cc: "Lee, Chun-Yi" , Linux Kernel Mailing List , linux-efi , the arch/x86 maintainers , keyrings@vger.kernel.org, linux-integrity , Kees Cook , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "Rafael J. Wysocki" , Pavel Machek , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Mimi Zohar Subject: Re: [PATCH 0/6][RFC] Add EFI secure key to key retention service Message-ID: <20180805163139.GB27062@linux-l9pv.suse> References: <20180805032119.20485-1-jlee@suse.com> 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 On Sun, Aug 05, 2018 at 09:25:56AM +0200, Ard Biesheuvel wrote: > Hello Chun,yi, > > On 5 August 2018 at 05:21, Lee, Chun-Yi wrote: > > When secure boot is enabled, only signed EFI binary can access > > EFI boot service variable before ExitBootService. Which means that > > the EFI boot service variable is secure. > > > > No it, isn't, and this is a very dangerous assumption to make. > > 'Secure' means different things to different people. 'Secure boot' is > a misnomer, since it is too vague: it should be called 'authenticated > boot', and the catch is that authentication using public-key crypto > does not involve secrets at all. The UEFI variable store was not > designed with confidentiality in mind, and assuming [given the > reputation of EFI on the implementation side] that you can use it to > keep secrets is rather unwise imho. > I agreed with you. Especially I can't refute the part of EFI implementation, manufacturers can not be fully trusted. I am thinking a case... Some machines provide setup mode. If user earses all manufacturer's reloaded keys and only enrolls their own key. Which means that user fully controls the authentication environment. Then the EFI boot service varible can be trusted by the user. But this case is too strict for normal user. Thanks for your review and comments. I will think more about your suggestions. Joey Lee