linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Dov Murik <dovmurik@linux.ibm.com>
Cc: linux-efi@vger.kernel.org, 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>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andrew Scull <ascull@google.com>,
	Dave Hansen <dave.hansen@intel.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	James Bottomley <jejb@linux.ibm.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
Subject: Re: [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area
Date: Mon, 3 Jan 2022 19:59:14 +0100	[thread overview]
Message-ID: <YdNHgtuVoLofL4cW@zn.tnic> (raw)
In-Reply-To: <20211129114251.3741721-1-dovmurik@linux.ibm.com>

On Mon, Nov 29, 2021 at 11:42:46AM +0000, Dov Murik wrote:
> As a usage example, consider a guest performing computations on
> encrypted files.  The Guest Owner provides the decryption key (= secret)
> using the secret injection mechanism.  The guest application reads the
> secret from the efi_secret filesystem and proceeds to decrypt the files
> into memory and then performs the needed computations on the content.
> 
> In this example, the host can't read the files from the disk image
> because they are encrypted.  Host can't read the decryption key because
> it is passed using the secret injection mechanism (= secure channel).
> Host can't read the decrypted content from memory because it's a
> confidential (memory-encrypted) guest.

So maybe I don't understand the example properly or something's missing
but why can't the guest owner simply scp the secrets into the guest? Why
is this special thing needed?

The secret below says "...kata-secrets" so this sounds like
something-automated-containers-thing where they'd profit from getting
secrets automatically supplied to the guest. But I guess there you can
scp too...

So what am I missing?

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

  parent reply	other threads:[~2022-01-03 18:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-29 11:42 [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area Dov Murik
2021-11-29 11:42 ` [PATCH v6 1/5] efi: Save location of EFI confidential computing area Dov Murik
2021-11-29 11:42 ` [PATCH v6 2/5] efi/libstub: Reserve confidential computing secret area Dov Murik
2021-11-29 11:42 ` [PATCH v6 3/5] virt: Add efi_secret module to expose confidential computing secrets Dov Murik
2021-12-06  7:58   ` kernel test robot
2021-11-29 11:42 ` [PATCH v6 4/5] efi: Load efi_secret module if EFI secret area is populated Dov Murik
2021-11-29 11:42 ` [PATCH v6 5/5] docs: security: Add coco/efi_secret documentation Dov Murik
2021-12-15 11:33 ` [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area Dov Murik
2022-01-03 18:59 ` Borislav Petkov [this message]
2022-01-04  7:02   ` Dov Murik
2022-01-04 18:26     ` Borislav Petkov
2022-01-05 11:43       ` Dr. David Alan Gilbert
2022-01-05 19:01         ` Borislav Petkov
2022-01-05 20:07           ` Dr. David Alan Gilbert
2022-01-07 11:59             ` Borislav Petkov
2022-01-07 19:16               ` Peter Gonda
2022-01-10 11:14                 ` Dov Murik
2022-01-10 16:27                 ` Dr. David Alan Gilbert

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=YdNHgtuVoLofL4cW@zn.tnic \
    --to=bp@suse.de \
    --cc=ak@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=ascull@google.com \
    --cc=ashish.kalra@amd.com \
    --cc=brijesh.singh@amd.com \
    --cc=dave.hansen@intel.com \
    --cc=dbuono@linux.vnet.ibm.com \
    --cc=dgilbert@redhat.com \
    --cc=dovmurik@linux.ibm.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).