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

Fri May 8 22:39:03 UTC 2020

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