Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp154220yba; Wed, 3 Apr 2019 06:22:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqxUtx3QD6+ug5SGyAHLfj+Q0RYUYCo2y+aBbAENSe6UTfKelQds1Gry7sGiVgTxbgav83Yc X-Received: by 2002:a65:6107:: with SMTP id z7mr58872718pgu.313.1554297733108; Wed, 03 Apr 2019 06:22:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554297733; cv=none; d=google.com; s=arc-20160816; b=QlKP2W0kcgyO+bBtap4uJeZ/duZK4yZ8dZH7amltAYt+FQIMueYZGDF+Gw7swqw2az z8YyDWbhdAwr6pXkEyYSQDkbuQFhoc75YdDqWtUZOpHnt/nfYCg9yTAohARFEpyKqWBm Cmd936hclQTzmSgysZhBDXKnoXWSbuCzEaAocBD0HtsRDjNOa7ChRe+MoKw3gevnpmEG fQUAEQgxrqsYKzmfJcBLx9i5Hm56UFDWJ4UXY8yNoVphRS0cBs5WyUMVEKP/wdlzastl 77S4tf5Ulz93ZmptYcEC369nBczM+VFZLigXfQUyDMzxaLtRGNBRJaYHtsCtfewz9lt/ VMYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=kxDKptdWoG7obuc2cd3NI4qJLwW7BiQ2oh7nic3KLF0=; b=IGL6lULqSdNmsB0zIMcT/9UFDsckuRQx2+kVPLMMVo0XM/9W23qcDAAZhI8A8i5STu IbFvZpDcCg522wycFqGW6+Qy/cxLW+fSNKTIBjD0T4V4g4jmgt9m+M46wsHf8FE/ok30 hZ2uwHxgETp8xHKhg2s0erB+JQgKnVGE1O8scdQyOALPcgLRobb/AlVaHZI0z/R1lDiG ITXjsKjlRyuBMimMcD4INoLXaRyGCUZ/IF8dg1LVZ12speQbslBu4GEB/QnAO/RI6hU8 zdLpUZuL455MJSYTOs/HVBktPJGwIMjgs0VwJVoH3OiDVSJmg+2HvpkAzLk0rmLGmZtJ CRvQ== 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 h23si13603857pgv.190.2019.04.03.06.21.57; Wed, 03 Apr 2019 06:22:13 -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 S1726387AbfDCNVR (ORCPT + 99 others); Wed, 3 Apr 2019 09:21:17 -0400 Received: from ozlabs.org ([203.11.71.1]:50537 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725959AbfDCNVR (ORCPT ); Wed, 3 Apr 2019 09:21:17 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 44Z6Cs5jdRz9sRW; Thu, 4 Apr 2019 00:21:13 +1100 (AEDT) From: Michael Ellerman To: Claudio Carvalho , linuxppc-dev@ozlabs.org, linux-efi@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Paul Mackerras , Benjamin Herrenschmidt , Ard Biesheuvel , Jeremy Kerr , Matthew Garret , Claudio Carvalho , Nayna Jain Subject: Re: [PATCH 0/4] Enabling secure boot on PowerNV systems In-Reply-To: <20190402181505.25037-1-cclaudio@linux.ibm.com> References: <20190402181505.25037-1-cclaudio@linux.ibm.com> Date: Thu, 04 Apr 2019 00:21:12 +1100 Message-ID: <87r2aj1ayf.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Claudio, Thanks for posting this. Claudio Carvalho writes: > This patch set is part of a series that implements secure boot on > PowerNV systems. > > In order to verify the OS kernel on PowerNV, secure boot requires X.509 > certificates trusted by the platform, the secure boot modes, and several > other pieces of information. These are stored in secure variables > controlled by OPAL, also known as OPAL secure variables. > > This patch set adds the following features: > > 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR > introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can > be used to manage the secure variables. > 2. Add support for OPAL secure variables by overwriting the EFI hooks > (get_variable, get_next_variable, set_variable and query_variable_info) > with OPAL call wrappers. There is probably a better way to add this > support, for example, we are investigating if we could register the > efivar_operations rather than overwriting the EFI hooks. In this patch > set, CONFIG_OPAL_SECVAR selects CONFIG_EFI. If, instead, we registered > efivar_operations, CONFIG_EFIVAR_FS would need to depend on > CONFIG_EFI|| CONFIG_OPAL_SECVAR. Comments or suggestions on the > preferred technique would be greatly appreciated. I am *very* reluctant to start selecting CONFIG_EFI on powerpc. Simply because we don't actually have EFI, and I worry we're going to both break assumptions in the EFI code as well as impose requirements on the powerpc code that aren't really necessary. So I'd definitely prefer we go the route of enabling efivarfs with an alternate backend. Better still would be a generic secure variable interface as Matt suggests, if the userspace tools can be relatively easily adapted to use that interface. cheers