From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cavan.codon.org.uk (cavan.codon.org.uk [176.126.240.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53D9E2F26 for ; Wed, 2 Feb 2022 06:54:45 +0000 (UTC) Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 87B0840A4A; Wed, 2 Feb 2022 06:54:43 +0000 (GMT) Date: Wed, 2 Feb 2022 06:54:43 +0000 From: Matthew Garrett To: Greg KH Cc: James Bottomley , Dov Murik , linux-efi@vger.kernel.org, Borislav Petkov , Ashish Kalra , Brijesh Singh , Tom Lendacky , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , Andi Kleen , Andrew Scull , Dave Hansen , "Dr. David Alan Gilbert" , Gerd Hoffmann , Lenny Szubowicz , Peter Gonda , Tobin Feldman-Fitzthum , Jim Cadden , Daniele Buono , linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Nayna Jain , dougmill@linux.vnet.ibm.com, gcwilson@linux.ibm.com, gjoyce@ibm.com, linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au, dja@axtens.net Subject: Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area Message-ID: <20220202065443.GA9249@srcf.ucam.org> References: <20220201124413.1093099-1-dovmurik@linux.ibm.com> <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com> <20220202040157.GA8019@srcf.ucam.org> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Wed, Feb 02, 2022 at 07:10:02AM +0100, Greg KH wrote: > On Wed, Feb 02, 2022 at 04:01:57AM +0000, Matthew Garrett wrote: > > We're talking about things that have massively different semantics. > > I see lots of different platforms trying to provide access to their > "secure" firmware data to userspace in different ways. That feels to me > like they are the same thing that userspace would care about in a > unified way. EFI variables are largely for the OS to provide information to the firmware, while this patchset is to provide information from the firmware to the OS. I don't see why we'd expect to use the same userland tooling for both. In the broader case - I don't think we *can* use the same userland tooling for everything. For example, the patches to add support for manipulating the Power secure boot keys originally attempted to make it look like efivars, but the underlying firmware semantics are sufficiently different that even exposing the same kernel interface wouldn't be a sufficient abstraction and userland would still need to behave differently. Exposing an interface that looks consistent but isn't is arguably worse for userland than exposing explicitly distinct interfaces.