From: Greg KH <gregkh@linuxfoundation.org> To: Matthew Garrett <mjg59@srcf.ucam.org> Cc: James Bottomley <jejb@linux.ibm.com>, Dov Murik <dovmurik@linux.ibm.com>, 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, 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 Date: Wed, 2 Feb 2022 08:05:23 +0100 [thread overview] Message-ID: <YfotMyQiQ66xfCOQ@kroah.com> (raw) In-Reply-To: <20220202065443.GA9249@srcf.ucam.org> On Wed, Feb 02, 2022 at 06:54:43AM +0000, Matthew Garrett wrote: > 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. I totally agree, I'm not worried about EFI variables here, I don't know why that came up. > 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. So what does userspace really need here? Just the ability to find if the platform has blobs that it cares about, and how to read/write them. 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? thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org> To: Matthew Garrett <mjg59@srcf.ucam.org> Cc: linux-efi@vger.kernel.org, Brijesh Singh <brijesh.singh@amd.com>, 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>, Dov Murik <dovmurik@linux.ibm.com>, 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, James Bottomley <jejb@linux.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>, 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: Wed, 2 Feb 2022 08:05:23 +0100 [thread overview] Message-ID: <YfotMyQiQ66xfCOQ@kroah.com> (raw) In-Reply-To: <20220202065443.GA9249@srcf.ucam.org> On Wed, Feb 02, 2022 at 06:54:43AM +0000, Matthew Garrett wrote: > 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. I totally agree, I'm not worried about EFI variables here, I don't know why that came up. > 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. So what does userspace really need here? Just the ability to find if the platform has blobs that it cares about, and how to read/write them. 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? thanks, greg k-h
next prev parent reply other threads:[~2022-02-02 7:05 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 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 [this message] 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=YfotMyQiQ66xfCOQ@kroah.com \ --to=gregkh@linuxfoundation.org \ --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=jcadden@ibm.com \ --cc=jejb@linux.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.