linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dov Murik <dovmurik@linux.ibm.com>
To: Greg KH <gregkh@linuxfoundation.org>,
	James Bottomley <jejb@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>,
	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, Dov Murik <dovmurik@linux.ibm.com>
Subject: Re: [PATCH v4 1/3] efi/libstub: Copy confidential computing secret area
Date: Wed, 20 Oct 2021 15:52:49 +0300	[thread overview]
Message-ID: <bfa4872d-f64a-0559-1c5d-c5d1ae333eee@linux.ibm.com> (raw)
In-Reply-To: <YXAHgkcfwSCBeCbh@kroah.com>



On 20/10/2021 15:11, Greg KH wrote:
> On Wed, Oct 20, 2021 at 08:00:28AM -0400, James Bottomley wrote:
>> On Wed, 2021-10-20 at 08:39 +0200, Greg KH wrote:
>>> On Wed, Oct 20, 2021 at 06:14:06AM +0000, Dov Murik wrote:
>> [...]
>>>> +	help
>>>> +	  Copy memory reserved by EFI for Confidential Computing (coco)
>>>> +	  injected secrets, if EFI exposes such a table entry.
>>>
>>> Why would you want to "copy" secret memory?
>>>
>>> This sounds really odd here, it sounds like you are opening up a
>>> security hole.  Are you sure this is the correct text that everyone
>>> on the "COCO" group agrees with?
>>
>> The way this works is that EFI covers the secret area with a boot time
>> handoff block, which means it gets destroyed as soon as
>> ExitBootServices is called as a security measure ... if you do nothing
>> the secret is shredded.  This means you need to make a copy of it
>> before that happens if there are secrets that need to live beyond the
>> EFI boot stub.
> 
> Ok, but "copy secrets" does sound really odd, so you all need a much
> better description here, and hopefully somewhere else in Documentation/
> to describe exactly what this new API is and is to be used for.
> 


So something like:


config EFI_COCO_SECRET
	bool "Keep the EFI Confidential Computing secret area"
	depends on EFI
	help
	  Confidential Computing platforms (such as AMD SEV) allow for
	  secrets injection during guest VM launch.  The secrets are
	  placed in a designated EFI memory area.  EFI destorys
	  the confidential computing secret area when ExitBootServices
	  is called.

	  In order to use the secrets in the kernel, the secret area
	  must be copied to kernel-reserved memory (before it is erased).

	  If you say Y here, the EFI stub will copy the EFI secret area (if
	  available) and reserve it for use inside the kernel.  This will
	  allow the virt/coco/efi_secret module to access the secrets.



and some new file like Documentation/security/coco/efi_secret.rst which
describes this whole protocol (from secret injection at VM launch
into an EFI page, through efistub and efi in linux, to the efi_secret
module which exposes the secrets).


Is that what you're looking for?



> Otherwise I read this as "hey a backdoor to read the secrets I wasn't
> supposed to be able to see!"
> 

Note that both EFI and kernel (and userspace, for that matter) are inside
the trusted zone in terms of AMD SEV (host/hypervisor => untrusted,
guest VM => trusted).  So it's OK for the guest kernel to see these secrets.


-Dov

> thanks,
> 
> greg k-h
> 

  reply	other threads:[~2021-10-20 12:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20  6:14 [PATCH v4 0/3] Allow guest access to EFI confidential computing secret area Dov Murik
2021-10-20  6:14 ` [PATCH v4 1/3] efi/libstub: Copy " Dov Murik
2021-10-20  6:39   ` Greg KH
2021-10-20  7:02     ` Ard Biesheuvel
2021-10-20  8:02     ` Dov Murik
2021-10-20 12:00     ` James Bottomley
2021-10-20 12:11       ` Greg KH
2021-10-20 12:52         ` Dov Murik [this message]
2021-10-20 13:59           ` Greg KH
2021-10-20  6:14 ` [PATCH v4 2/3] efi: Reserve " Dov Murik
2021-10-20  6:40   ` Greg KH
2021-10-20  8:19     ` Dov Murik
2021-10-20  6:14 ` [PATCH v4 3/3] virt: Add efi_secret module to expose confidential computing secrets 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=bfa4872d-f64a-0559-1c5d-c5d1ae333eee@linux.ibm.com \
    --to=dovmurik@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=gregkh@linuxfoundation.org \
    --cc=jcadden@ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).