From: James Bottomley <jejb@linux.ibm.com>
To: Stefan Berger <stefanb@linux.ibm.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH 2/2] tpm: add backend for mssim
Date: Tue, 10 Jan 2023 09:14:43 -0500 [thread overview]
Message-ID: <8a62ef36fe784fe8ef71bcd795d2bba169502ef7.camel@linux.ibm.com> (raw)
In-Reply-To: <c15c7dd1-0ac2-a00c-0895-2ea41eb7414d@linux.ibm.com>
On Mon, 2023-01-09 at 16:06 -0500, Stefan Berger wrote:
> On 1/9/23 14:01, Stefan Berger wrote:
[...]
> If you use TPM 2 for attestation then certain TPM 2 state migration
> scenarios may become problematic. One could construct a scenario
> where attestation preceeds some action that requires trust to have
> been established in the system in the preceeding attestation step and
> support for snapshotting the state of the TPM 2 could become an issue
> if I was to wait for the attestation to have been concluded and then
> I quickly restart a different snapshot that is not trustworthy and
> the client proceeds thinking that the system is trustworthy (maybe a
> few SYNs from the client went into the void)
You're over thinking this. For a non-confidential VM, Migration gives
you a saved image you can always replay from (this is seen as a feature
for fast starts) and if you use the tpm_simulator the TPM state is
stored in the migration image, so you can always roll it back if you
have access to the migration file. Saving the image state is also a
huge problem because the TPM seeds are in the clear if the migration
image isn't encrypted. The other big problem is that an external
software TPM is always going to give up its state to the service
provider, regardless of migration, so you have to have some trust in
the provider and thus you'd also have to trust them with the migration
replay policy. For Confidential VMs, this is a bit different because
the vTPM runs in a secure ring inside the confidential enclave and the
secure migration agent ensures that either migration and startup happen
or migration doesn't happen at all, so for them you don't have to worry
about rollback.
Provided you can trust the vTPM provider, having external state not
stored in the migration image has the potential actually to solve the
rollback problem because you could keep the TPM clock running and
potentially increase the reset count, so migrations would show up in
TPM quotes and you don't have control of the state of the vTPM to
replay it.
James
next prev parent reply other threads:[~2023-01-10 15:24 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-15 18:01 [PATCH 0/2] tpm: add mssim backend James Bottomley
2022-12-15 18:01 ` [PATCH 1/2] tpm: convert tpmdev options processing to new visitor format James Bottomley
2022-12-15 18:01 ` [PATCH 2/2] tpm: add backend for mssim James Bottomley
2022-12-15 18:46 ` Stefan Berger
2022-12-15 19:22 ` James Bottomley
2022-12-15 19:35 ` Stefan Berger
2022-12-15 19:40 ` James Bottomley
2022-12-15 19:57 ` Stefan Berger
2022-12-15 20:07 ` James Bottomley
2022-12-15 20:22 ` Stefan Berger
2022-12-15 20:30 ` James Bottomley
2022-12-15 20:53 ` Stefan Berger
2022-12-16 10:27 ` Daniel P. Berrangé
2022-12-16 12:28 ` Stefan Berger
2022-12-16 12:54 ` Daniel P. Berrangé
2022-12-16 13:32 ` Stefan Berger
2022-12-16 13:53 ` James Bottomley
2022-12-16 14:01 ` Stefan Berger
2022-12-19 11:49 ` Stefan Berger
2022-12-19 13:02 ` James Bottomley
2022-12-19 14:01 ` Stefan Berger
2022-12-16 14:29 ` Daniel P. Berrangé
2022-12-16 14:55 ` Stefan Berger
2022-12-16 15:48 ` James Bottomley
2022-12-16 16:08 ` Stefan Berger
2022-12-16 16:13 ` James Bottomley
2022-12-16 16:21 ` Stefan Berger
2023-01-09 16:59 ` Dr. David Alan Gilbert
2023-01-09 17:43 ` James Bottomley
2023-01-09 17:52 ` Dr. David Alan Gilbert
2023-01-09 17:55 ` James Bottomley
2023-01-09 18:34 ` Stefan Berger
2023-01-09 18:51 ` James Bottomley
2023-01-09 18:54 ` Dr. David Alan Gilbert
2023-01-09 18:59 ` James Bottomley
2023-01-09 19:01 ` Stefan Berger
2023-01-09 21:06 ` Stefan Berger
2023-01-10 14:14 ` James Bottomley [this message]
2023-01-10 14:47 ` Stefan Berger
2023-01-10 14:55 ` James Bottomley
2023-01-10 15:00 ` Stefan Berger
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=8a62ef36fe784fe8ef71bcd795d2bba169502ef7.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanb@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).