Re: [PATCH v1 0/8] Introducing TPM Proxy device support

(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 >> >