From: Dov Murik <dovmurik@linux.ibm.com>
To: linux-coco@lists.linux.dev
Cc: "Dov Murik" <dovmurik@linux.ibm.com>,
"Tobin Feldman-Fitzthum" <tobin@linux.ibm.com>,
"James Bottomley" <jejb@linux.ibm.com>,
amd-sev-snp@lists.suse.com,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>
Subject: Secure vTPMs for confidential VMs
Date: Tue, 20 Sep 2022 23:28:15 +0300 [thread overview]
Message-ID: <84d6ee10-ff8a-a121-d62f-19becf400e75@linux.ibm.com> (raw)
Hello,
Tobin and I gave a talk in KVM Forum 2022 last week about Unifying
Confidential Attestation [1]. During the KVM Forum and Linux Plumbers
2022 we had several conversations with various attendees about using
secure virtual TPMs to attest confidential VMs.
We want to use the linux-coco mailing list to start community discussion
about various options and tradeoffs for implementing secure vTPMs.
Emulating hardware TPMs has an advantage that guest software already
uses TPM devices to measure boot sequence components (firmware,
bootloader, kernel, initrd) and runtime events (IMA in Linux). We know
that this currently works with vTPMs backed by the VMM implementation,
such as QEMU's tpm device which is connected to swtpm running on the
host.
As far as we know, current vTPM solutions are insecure in the
confidential computing setting, because the TPM code is running on the
untrusted host, and communication between the guest and the TPM
component is visible and modifiable by the untrusted host. This allows
the untrusted host to fake measurements or steal sensitive keys from the
TPM memory/NVDATA.
We so far recognized three issues that should be further researched in
order to implement secure vTPMs for confidential VMs; these are TPM
provisioning, implementations in TEEs, and guest enlightment.
* TPM provisioning: The TPM contains sensitive information such as EK
private key which should not be accessible to the host and to the guest.
How should such information be delivered to the vTPM when starting a new
VM? If we provision encrypted NVDATA, who has the key to decrypt it?
If we provision it with "classic" TEE secret injection, we need to do it
quite early in the VM launch sequence (even before the firmware starts?).
One suggestion is to use an ephemeral EK, generated at launch by the
vTPM. The system may start to boot using such a TPM, but once we want
to unseal secrets (for example, to unlock a LUKS partition), we need
something persistent inside the TPM (or re-seal the key for each TPM).
Ephemeral TPMs might be a useful first step.
* Implementation in TEEs: SNP introduced VPMLs, and AMD's linux-SVSM
running in VPML0 can also run vTPM code to handle TPM requests from the
guest running in VMPL1. Such a solution is not applicable as-is to
other TEEs (SEV, TDX). People suggested running vTPMs in a separate
confidential VMs, and somehow connect the tenant's guest to the TPM VM;
but we'll need a way to secure this communication channel.
* Guest enlightment: Guest software currently interacts with the TPM by
writing commands to a memory-mapped IO page (GPA 0xfed40000) and reading
responses from that page. We want such writes to trigger the code of
our vTPM (for whatever implementation we choose). Our current early
experience with TPM running in linux-SVSM required adding "exit-guest"
calls after writing commands to the IO page, in order to allow the SVSM
to run and recognize the incoming command. Ideally, we'd like a
solution that doesn't require modifying all the TPM drivers out there
(in Linux, Windows, OVMF, grub, ...).
We're sure there are other issues as well, but these are the main ones
we encountered so far. We'd like to hear the community's feedback and
ideas as early as possible.
Thanks,
Tobin and Dov.
[1] https://static.sched.com/hosted_files/kvmforum2022/02/Unifying-Confidential-Attestation-KVM-Forum-2022.pdf
next reply other threads:[~2022-09-20 20:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 20:28 Dov Murik [this message]
2022-09-21 8:49 ` Secure vTPMs for confidential VMs Jörg Rödel
2022-09-21 17:07 ` Tom Lendacky
2022-09-22 21:14 ` Tobin Feldman-Fitzthum
2022-09-22 22:01 ` [EXTERNAL] " Jon Lange
2022-09-21 9:36 ` Daniel P. Berrangé
2022-10-03 7:42 ` 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=84d6ee10-ff8a-a121-d62f-19becf400e75@linux.ibm.com \
--to=dovmurik@linux.ibm.com \
--cc=amd-sev-snp@lists.suse.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jejb@linux.ibm.com \
--cc=linux-coco@lists.linux.dev \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).