From: James Bottomley <jejb@linux.ibm.com> To: Greg KH <gregkh@linuxfoundation.org>, Dov Murik <dovmurik@linux.ibm.com> Cc: linux-efi@vger.kernel.org, Borislav Petkov <bp@suse.de>, Ashish Kalra <ashish.kalra@amd.com>, Brijesh Singh <brijesh.singh@amd.com>, Tom Lendacky <thomas.lendacky@amd.com>, Ard Biesheuvel <ardb@kernel.org>, James Morris <jmorris@namei.org>, "Serge E. Hallyn" <serge@hallyn.com>, Andi Kleen <ak@linux.intel.com>, Andrew Scull <ascull@google.com>, Dave Hansen <dave.hansen@intel.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Lenny Szubowicz <lszubowi@redhat.com>, Peter Gonda <pgonda@google.com>, Tobin Feldman-Fitzthum <tobin@linux.ibm.com>, Jim Cadden <jcadden@ibm.com>, Daniele Buono <dbuono@linux.vnet.ibm.com>, linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Nayna Jain <nayna@linux.ibm.com>, dougmill@linux.vnet.ibm.com, gcwilson@linux.ibm.com, gjoyce@ibm.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, 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 Date: Tue, 01 Feb 2022 09:24:50 -0500 [thread overview] Message-ID: <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com> (raw) In-Reply-To: <Yfk6vEuZFtgtA+G+@kroah.com> [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/ > 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 <common path prefix>/efivar <common path prefix>/coco 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. James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <jejb@linux.ibm.com> To: Greg KH <gregkh@linuxfoundation.org>, Dov Murik <dovmurik@linux.ibm.com> Cc: linux-efi@vger.kernel.org, Brijesh Singh <brijesh.singh@amd.com>, mjg59@srcf.ucam.org, Lenny Szubowicz <lszubowi@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, gcwilson@linux.ibm.com, Ard Biesheuvel <ardb@kernel.org>, Daniele Buono <dbuono@linux.vnet.ibm.com>, Andi Kleen <ak@linux.intel.com>, Nayna Jain <nayna@linux.ibm.com>, James Morris <jmorris@namei.org>, Jim Cadden <jcadden@ibm.com>, Peter Gonda <pgonda@google.com>, Borislav Petkov <bp@suse.de>, "Serge E. Hallyn" <serge@hallyn.com>, Tom Lendacky <thomas.lendacky@amd.com>, Ashish Kalra <ashish.kalra@amd.com>, dougmill@linux.vnet.ibm.com, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Tobin Feldman-Fitzthum <tobin@linux.ibm.com>, linux-coco@lists.linux.dev, gjoyce@ibm.com, dja@axtens.net, Dave Hansen <dave.hansen@intel.com>, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Andrew Scull <ascull@google.com> Subject: Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area Date: Tue, 01 Feb 2022 09:24:50 -0500 [thread overview] Message-ID: <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com> (raw) In-Reply-To: <Yfk6vEuZFtgtA+G+@kroah.com> [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/ > 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 <common path prefix>/efivar <common path prefix>/coco 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. James
next prev parent reply other threads:[~2022-02-01 14:25 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-01 12:44 [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area Dov Murik 2022-02-01 12:44 ` [PATCH v7 1/5] efi: Save location of EFI confidential computing area Dov Murik 2022-02-02 8:38 ` Gerd Hoffmann 2022-02-01 12:44 ` [PATCH v7 2/5] efi/libstub: Reserve confidential computing secret area Dov Murik 2022-02-02 8:41 ` Gerd Hoffmann 2022-02-02 11:13 ` Dov Murik 2022-02-01 12:44 ` [PATCH v7 3/5] virt: Add efi_secret module to expose confidential computing secrets Dov Murik 2022-02-02 8:45 ` Gerd Hoffmann 2022-02-02 10:55 ` Dov Murik 2022-02-01 12:44 ` [PATCH v7 4/5] efi: Load efi_secret module if EFI secret area is populated Dov Murik 2022-02-02 8:47 ` Gerd Hoffmann 2022-02-02 11:08 ` Dov Murik 2022-02-02 14:31 ` Gerd Hoffmann 2022-02-02 15:09 ` Dov Murik 2022-02-03 6:16 ` Gerd Hoffmann 2022-02-03 11:03 ` Dov Murik 2022-02-03 12:11 ` Gerd Hoffmann 2022-02-01 12:44 ` [PATCH v7 5/5] docs: security: Add coco/efi_secret documentation Dov Murik 2022-02-02 8:49 ` Gerd Hoffmann 2022-02-02 11:19 ` Dov Murik 2022-02-01 13:50 ` [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area Greg KH 2022-02-01 14:24 ` James Bottomley [this message] 2022-02-01 14:24 ` James Bottomley 2022-02-01 14:41 ` Greg KH 2022-02-01 14:41 ` Greg KH 2022-02-01 15:05 ` James Bottomley 2022-02-01 15:05 ` James Bottomley 2022-02-01 18:07 ` Dr. David Alan Gilbert 2022-02-01 18:07 ` Dr. David Alan Gilbert 2022-02-02 4:01 ` Matthew Garrett 2022-02-02 4:01 ` Matthew Garrett 2022-02-02 6:10 ` Greg KH 2022-02-02 6:10 ` Greg KH 2022-02-02 6:54 ` Matthew Garrett 2022-02-02 6:54 ` Matthew Garrett 2022-02-02 7:05 ` Greg KH 2022-02-02 7:05 ` Greg KH 2022-02-02 7:10 ` Matthew Garrett 2022-02-02 7:10 ` Matthew Garrett 2022-02-02 7:22 ` Ard Biesheuvel 2022-02-02 7:22 ` Ard Biesheuvel 2022-02-02 8:04 ` Matthew Garrett 2022-02-02 8:04 ` Matthew Garrett 2022-02-02 8:25 ` Greg KH 2022-02-02 8:25 ` Greg KH 2022-02-09 0:19 ` Nayna 2022-02-09 0:25 ` Nayna 2022-02-09 0:25 ` Nayna 2022-02-02 8:36 ` Gerd Hoffmann 2022-02-02 8:36 ` Gerd Hoffmann 2022-02-02 8:45 ` Matthew Garrett 2022-02-02 8:45 ` Matthew Garrett 2022-02-07 18:50 ` Dov Murik 2022-02-07 18:50 ` Dov Murik
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com \ --to=jejb@linux.ibm.com \ --cc=ak@linux.intel.com \ --cc=ardb@kernel.org \ --cc=ascull@google.com \ --cc=ashish.kalra@amd.com \ --cc=bp@suse.de \ --cc=brijesh.singh@amd.com \ --cc=dave.hansen@intel.com \ --cc=dbuono@linux.vnet.ibm.com \ --cc=dgilbert@redhat.com \ --cc=dja@axtens.net \ --cc=dougmill@linux.vnet.ibm.com \ --cc=dovmurik@linux.ibm.com \ --cc=gcwilson@linux.ibm.com \ --cc=gjoyce@ibm.com \ --cc=gregkh@linuxfoundation.org \ --cc=jcadden@ibm.com \ --cc=jmorris@namei.org \ --cc=kraxel@redhat.com \ --cc=linux-coco@lists.linux.dev \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=lszubowi@redhat.com \ --cc=mjg59@srcf.ucam.org \ --cc=mpe@ellerman.id.au \ --cc=nayna@linux.ibm.com \ --cc=pgonda@google.com \ --cc=serge@hallyn.com \ --cc=thomas.lendacky@amd.com \ --cc=tobin@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.