From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 410FC2C82 for ; Tue, 1 Feb 2022 14:41:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19819C340EB; Tue, 1 Feb 2022 14:41:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643726482; bh=4sxxBUCUngbxSjMsWZ+Vhdr/PDT3NXWPXmrp4T/JV24=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JsViJyuTsNcR7cmH3MW9ScowqbBG6PK76wdZIFQnQv/jFd4F1DUATML5W8uxrUP3D 5qYQ7V+/ybnm/5F4GYw4GOwAUmj8oytNQM/UihGDvZbzQ0y1pD0N191mvZ4c6ocQmx trc8KkrOshzAwcnNgbOVhAMTqSuMRq/4nODL2GzY= Date: Tue, 1 Feb 2022 15:41:20 +0100 From: Greg KH To: James Bottomley Cc: 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, mjg59@srcf.ucam.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: References: <20220201124413.1093099-1-dovmurik@linux.ibm.com> <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com> 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: <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com> On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote: > [cc's added] > On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote: > > On Tue, Feb 01, 2022 at 12:44:08PM +0000, Dov Murik wrote: > [...] > > > # ls -la /sys/kernel/security/coco/efi_secret > > > total 0 > > > drwxr-xr-x 2 root root 0 Jun 28 11:55 . > > > drwxr-xr-x 3 root root 0 Jun 28 11:54 .. > > > -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec- > > > 06879ce3da0b > > > -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e- > > > d3a0b54312c6 > > > -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d- > > > ff17f78864d2 > > > > Please see my comments on the powerpc version of this type of thing: > > > > https://lore.kernel.org/r/20220122005637.28199-1-nayna@linux.ibm.com > > If you want a debate, actually cc'ing the people on the other thread > would have been a good start ... > > For those added, this patch series is at: > > https://lore.kernel.org/all/20220201124413.1093099-1-dovmurik@linux.ibm.com/ Thanks for adding everyone. > > You all need to work together to come up with a unified place for > > this and stop making it platform-specific. > > I'm not entirely sure of that. If you look at the differences between > EFI variables and the COCO proposal: the former has an update API > which, in the case of signed variables, is rather complex and a UC16 > content requirement. The latter is binary data with read only/delete. > Plus each variable in EFI is described by a GUID, so having a directory > of random guids, some of which behave like COCO secrets and some of > which are EFI variables is going to be incredibly confusing (and also > break all our current listing tools which seems somewhat undesirable). > > So we could end up with > > /efivar > /coco The powerpc stuff is not efi. But yes, that is messy here. But why doesn't the powerpc follow the coco standard? > To achieve the separation, but I really don't see what this buys us. > Both filesystems would likely end up with different backends because of > the semantic differences and we can easily start now in different > places (effectively we've already done this for efi variables) and > unify later if that is the chosen direction, so it doesn't look like a > blocker. > > > Until then, we can't take this. > > I don't believe anyone was asking you to take it. I was on the review list...