From: "Jörg Rödel" <jroedel@suse.de>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>,
linux-coco@lists.linux.dev, amd-sev-snp@lists.suse.com
Subject: Re: SVSM initiated early attestation / guest secrets injection
Date: Tue, 17 Jan 2023 17:53:33 +0100 [thread overview]
Message-ID: <Y8bSjVLLzF87X7V3@suse.de> (raw)
In-Reply-To: <Y8WFnFAzPrFiDHNP@redhat.com>
On Mon, Jan 16, 2023 at 05:13:00PM +0000, Daniel P. Berrangé wrote:
> IMHO it is undesirable to build a reliance on a specific bootloader.
>
> My desire is that we have the stateful TPM in SVSM, such that once
> the UEFI firmware starts everything functions identically to how
> it would in bare metal or non-confidential VMs with a TPM. eg the
> ability to use all the normal Linux tools, and especially the
> standard systemd integration with LUKS and TPMs.
Yes, a secure stateful TPM is my goal as well. Btw, I thought a bit more
about your proposal, and if the injected secret at SVSM init time is the
TPM state, then the SVSM will keep the actual secret (== LUKS key) sealed
until the boot measurements (bootloader + configuration) happened.
This invalidates the attack I described earlier in this thread, as
injected software from the CSP still has no way to fake these
measurments to do the unsealing.
After the bootloader gets the LUKS key it can load kernel and initrd
from encrypted storage, so that there is no immediate need to measure
those.
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
prev parent reply other threads:[~2023-01-17 16:53 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
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 [this message]
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=Y8bSjVLLzF87X7V3@suse.de \
--to=jroedel@suse.de \
--cc=amd-sev-snp@lists.suse.com \
--cc=berrange@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).