(CCing Mike Roth since he implemented the QEMU support for this device)
On 5/8/20 5:18 PM, Stefan Berger wrote:
On 5/8/20 8:06 AM, Daniel Henrique Barboza wrote:
Hello,
This series implements a new device type for Libvirt called
"TPM Proxy". This device acts as a proxy for TPM requisitions
that the guest can make for an existing TPM Resource Manager
in the host. The TPM Resource Manager multiplexes TPM access
to multiple processes, allowing more than one process (guest)
to use the host TPM at the same time.
A guest using a TPM Proxy device does not have access to all
possible TPM features. In that case the guest will need to
'... does not have access to all possible TPM features': Is this device filtering? Since I never used this device, I am wondering what does this mean? What is the usage model of this device and in what case do you intend to use it?
Do you give any guest now access to the host HW TPM and its PCRs and let the guest extend them? That's not something you would want, at least not for untrusted guests... keeping the device busy creating keys or loading it up with keys is another possible issue.
This device is part of the machinery the guest need to orchestrate with the PPC64
Ultravisor the transition to the Secure VM (SVM) mode. Inside QEMU, the
'host-path' provided in this device will be used with the following hypercall:
- H_TPM_COMM (0xef10)
For TPM_COMM_OP_EXECUTE operation:
Send a request to a TPM and receive a response, opening a new TPM session
if one has not already been opened.
For TPM_COMM_OP_CLOSE_SESSION operation:
Close the existing TPM session, if any.
This was extracted from docs/specs/ppc-spapr-uv-hcalls.txt in QEMU tree. This
document also has a use case notes for this specific hypercall and how it
interacts with the TPM Resource Manager:
----
Use-case/notes:
SVM filesystems are encrypted using a symmetric key. This key is then
wrapped/encrypted using the public key of a trusted system which has the
private key stored in the system's TPM. An Ultravisor will use this
hcall to unwrap/unseal the symmetric key using the system's TPM device
or a TPM Resource Manager associated with the device.
The Ultravisor sets up a separate session key with the TPM in advance
during host system boot. All sensitive in and out values will be
encrypted using the session key. Though the hypervisor will see the 'in'
and 'out' buffers in raw form, any sensitive contents will generally be
encrypted using this session key.
----
I am not aware of any other use case for this device, aside from helping enable
SVM mode for PPC64 guests in coordination with an Ultravisor. Hope this clarifies
a bit what role the TPM Proxy/spapr-tpm-proxy plays out.
All this said, I made the decision to not treat it as a new type of the regular
vTPM device in Libvirt, given that there is no restriction of a guest using both
devices at the same time and the TPM Proxy plays a different role than vTPM. If we
decide that allowing both devices is a bad idea then we can limit the guest to
use either one or the other. In that case, we can discuss whether it makes sense
to change the logic in this series to make spapr-tpm-proxy another TPM passthrough
model like tpm-spapr, instead of creating a new device type.
Thanks,
DHB
assign a vTPM device (tpm-spapr for PPC64). There is no restrictions
of using both a vTPM and a TPM Proxy device at the same time,
but only one TPM Proxy is allowed per guest.
At this moment, this device exists only for QEMU pSeries guests.
A "model" field was added device to allow more models to be added
when/if other architectures implements it.
Daniel Henrique Barboza (8):
docs: documentation and schema for the new TPM Proxy device
qemu: Extend QEMU capabilities with 'spapr-tpm-proxy'
conf, qemu: adding VIR_DOMAIN_DEVICE_TPMPROXY device
domain_conf.c: XML parsing for VIR_DOMAIN_DEVICE_TPMPROXY
tests: add test for domain XML with TPM Proxy device model
qemu: build command line for the TPM Proxy device
tests/qemuxml2argvtest.c: add TPM Proxy command line test
docs/news.xml: update for the new TPM Proxy device
docs/formatdomain.html.in | 42 +++++
docs/news.xml | 14 ++
docs/schemas/domaincommon.rng | 18 ++
src/conf/domain_capabilities.c | 1 +
src/conf/domain_conf.c | 160 ++++++++++++++++++
src/conf/domain_conf.h | 18 ++
src/conf/virconftypes.h | 3 +
src/libvirt_private.syms | 2 +
src/qemu/qemu_alias.c | 16 ++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 21 +++
src/qemu/qemu_domain.c | 14 ++
src/qemu/qemu_domain_address.c | 2 +
src/qemu/qemu_driver.c | 5 +
src/qemu/qemu_hotplug.c | 3 +
src/qemu/qemu_validate.c | 37 ++++
.../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
tests/qemuxml2argvdata/ppc64-tpmproxy.args | 28 +++
tests/qemuxml2argvdata/ppc64-tpmproxy.xml | 31 ++++
tests/qemuxml2argvtest.c | 4 +
tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml | 37 ++++
tests/qemuxml2xmltest.c | 4 +
24 files changed, 465 insertions(+)
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.args
create mode 100644 tests/qemuxml2argvdata/ppc64-tpmproxy.xml
create mode 100644 tests/qemuxml2xmloutdata/ppc64-tpmproxy.xml
