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 5D70BC433F5 for ; Wed, 2 Feb 2022 06:10:53 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JpWd74K7lz3cNP for ; Wed, 2 Feb 2022 17:10:51 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=ld+tSCVM; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=2604:1380:4601:e00::1; helo=ams.source.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=ld+tSCVM; dkim-atps=neutral Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JpWcN2V15z2xrm for ; Wed, 2 Feb 2022 17:10:11 +1100 (AEDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 27B7FB83012; Wed, 2 Feb 2022 06:10:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2098FC004E1; Wed, 2 Feb 2022 06:10:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643782204; bh=o9OIrNJyZoJDYTVkKluL49dvJyVfEvgp3uWhpxsqSmQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ld+tSCVMYvFZDbuSb+SfbwOFsGI+9nN9mO4Xs6IEK+rExQGRHD3EcKPX+8kNRKwX/ 7WqbwZzDUrH4ElEfoNwbTPZO6+2veEg1IygbQyrLDAq7iaDX3oLWPzMoMfer+TBUyn jOjhBdeAk6RyCCnKbDyYnrMNwmdV4EOuYY4dJyos= Date: Wed, 2 Feb 2022 07:10:02 +0100 From: Greg KH To: Matthew Garrett Subject: Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area Message-ID: 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: <20220202040157.GA8019@srcf.ucam.org> 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 04:01:57AM +0000, Matthew Garrett wrote: > On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote: > > On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote: > > > You all need to work together to come up with a unified place for > > > this and stop making it platform-specific. > > 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. Unless we expeect userspace tools to have to be platform-specific for all of this? That does not seem wise. what am I missing here? thanks, greg k-h