From: "Jörg Rödel" <jroedel@suse.de>
To: James Bottomley <jejb@linux.ibm.com>
Cc: "Christophe de Dinechin Dupont de Dinechin" <cdupontd@redhat.com>,
"\"Daniel P. Berrangé\"" <berrange@redhat.com>,
linux-coco@lists.linux.dev, amd-sev-snp@lists.suse.com
Subject: Re: SVSM initiated early attestation / guest secrets injection
Date: Thu, 19 Jan 2023 22:18:45 +0100 [thread overview]
Message-ID: <Y8mztTGpZbWi89sn@suse.de> (raw)
In-Reply-To: <f86f8d6844f1166a6c641df3fa437cad59bcee9a.camel@linux.ibm.com>
On Thu, Jan 19, 2023 at 09:10:48AM -0500, James Bottomley wrote:
> Yes, you have to think about this. Possessing the secrets is the
> problem if you don't trust what you've mounted, so in the original
> prototype the secrets got destroyed if they weren't used (as in you
> couldn't crypto mount the disk), so you can fallback to a potentially
> untrusted disk if you can ensure the secrets can't be leaked. I
> suppose secret destruction and fallback should be a configurable policy
> of the system instead of hard coded as I did in the initial prototype.
Is this still an issue in the SVSM version of this? The secrets will
stay in SVSM memory at VMPL0 and the higher VMPLs will not be able to
access them until they proved that only trusted software was loaded.
Regards,
--
Jörg Rödel
jroedel@suse.de
SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
next prev parent reply other threads:[~2023-01-19 21:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 14:39 SVSM initiated early attestation / guest secrets injection Daniel P. Berrangé
2023-01-13 17:22 ` Jörg Rödel
2023-01-13 18:02 ` James Bottomley
2023-01-14 16:57 ` Jörg Rödel
2023-01-19 14:05 ` Christophe de Dinechin Dupont de Dinechin
2023-01-19 14:10 ` James Bottomley
2023-01-19 21:18 ` Jörg Rödel [this message]
2023-01-19 21:29 ` James Bottomley
2023-01-20 8:37 ` Jörg Rödel
2023-01-20 8:57 ` Daniel P. Berrangé
2023-01-20 12:39 ` James Bottomley
2023-01-20 12:51 ` Daniel P. Berrangé
2023-01-20 17:10 ` James Bottomley
2023-01-20 12:32 ` James Bottomley
2023-01-13 18:28 ` Daniel P. Berrangé
2023-01-13 18:52 ` Dionna Amalie Glaze
2023-01-16 9:36 ` Daniel P. Berrangé
2023-01-14 17:08 ` Jörg Rödel
2023-01-14 18:22 ` James Bottomley
2023-01-16 16:55 ` Jörg Rödel
2023-01-16 16:59 ` James Bottomley
2023-01-17 16:47 ` Jörg Rödel
2023-01-16 17:13 ` Daniel P. Berrangé
2023-01-17 16:53 ` Jörg Rödel
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=Y8mztTGpZbWi89sn@suse.de \
--to=jroedel@suse.de \
--cc=amd-sev-snp@lists.suse.com \
--cc=berrange@redhat.com \
--cc=cdupontd@redhat.com \
--cc=jejb@linux.ibm.com \
--cc=linux-coco@lists.linux.dev \
/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).