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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF47CC433EF for ; Wed, 2 Feb 2022 07:10:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231766AbiBBHKY (ORCPT ); Wed, 2 Feb 2022 02:10:24 -0500 Received: from cavan.codon.org.uk ([176.126.240.207]:50482 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231321AbiBBHKY (ORCPT ); Wed, 2 Feb 2022 02:10:24 -0500 Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 56FE540A51; Wed, 2 Feb 2022 07:10:23 +0000 (GMT) Date: Wed, 2 Feb 2022 07:10:23 +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: <20220202071023.GA9489@srcf.ucam.org> References: <20220201124413.1093099-1-dovmurik@linux.ibm.com> <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com> <20220202040157.GA8019@srcf.ucam.org> <20220202065443.GA9249@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) Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Wed, Feb 02, 2022 at 08:05:23AM +0100, Greg KH wrote: > I see different platform patches trying to stick these blobs in > different locations and ways to access (securityfs, sysfs, char device > node), which seems crazy to me. Why can't we at least pick one way to > access these to start with, and then have the filesystem layout be > platform-specific as needed, which will give the correct hints to > userspace as to what it needs to do here? Which other examples are you thinking of? I think this conversation may have accidentally become conflated with a different prior one and now we're talking at cross purposes.