From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7DC67C433EF for ; Wed, 2 Feb 2022 20:59:28 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JpvLQ6gQXz3clm for ; Thu, 3 Feb 2022 07:59:26 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=neutral (access neither permitted nor denied) smtp.mailfrom=codon.org.uk (client-ip=2a00:1098:84:22e::2; helo=cavan.codon.org.uk; envelope-from=mjg59@codon.org.uk; receiver=) Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JpXbp1Z16z30Bc for ; Wed, 2 Feb 2022 17:54:46 +1100 (AEDT) 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 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> 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) X-Mailman-Approved-At: Thu, 03 Feb 2022 07:58:06 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-efi@vger.kernel.org, Brijesh Singh , Lenny Szubowicz , Gerd Hoffmann , gcwilson@linux.ibm.com, Ard Biesheuvel , Daniele Buono , Andi Kleen , Nayna Jain , James Morris , Dov Murik , Jim Cadden , Peter Gonda , Borislav Petkov , "Serge E. Hallyn" , Tom Lendacky , Ashish Kalra , dougmill@linux.vnet.ibm.com, James Bottomley , "Dr. David Alan Gilbert" , Tobin Feldman-Fitzthum , linux-coco@lists.linux.dev, gjoyce@ibm.com, dja@axtens.net, Dave Hansen , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Andrew Scull Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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.