On 5/8/20 5:39 PM, Daniel Henrique Barboza wrote:
(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.
No I think both should be accessible. H_COMM_TPM would only be used at
the start of the secure VM, right? It should probably shut down once
it's not needed anymore so it cannot be abused by anything that happens
to want to abuse H_COMM_TPM , like a malicious driver in Linux or so if
that could be implemented. But that's obviously not something to worry
about on the libvirt level, but I didn't understand what this devices
exposes.
I looked over the patches. They look good to me on first glance.
Stefan
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
