From: Matthew Garrett <mjg59@srcf.ucam.org>
To: James Bottomley <jejb@linux.ibm.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
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 04:01:57 +0000 [thread overview]
Message-ID: <20220202040157.GA8019@srcf.ucam.org> (raw)
In-Reply-To: <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com>
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. How
do we expose that without an unwieldy API that has to try to be a
superset of everything implemented, which then has to be extended when
yet another implementation shows up with another behavioural quirk? EFI
variables already need extremely careful handling to avoid rm -rf /sys
bricking the system - should we impose that on everything, or should we
allow the underlying implementation to leak through in some ways?
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: James Bottomley <jejb@linux.ibm.com>
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,
"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>,
Greg KH <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: Wed, 2 Feb 2022 04:01:57 +0000 [thread overview]
Message-ID: <20220202040157.GA8019@srcf.ucam.org> (raw)
In-Reply-To: <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com>
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. How
do we expose that without an unwieldy API that has to try to be a
superset of everything implemented, which then has to be extended when
yet another implementation shows up with another behavioural quirk? EFI
variables already need extremely careful handling to avoid rm -rf /sys
bricking the system - should we impose that on everything, or should we
allow the underlying implementation to leak through in some ways?
next prev parent reply other threads:[~2022-02-02 4:15 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 [this message]
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=20220202040157.GA8019@srcf.ucam.org \
--to=mjg59@srcf.ucam.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=gregkh@linuxfoundation.org \
--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=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: link
Be 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.