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

Daniel Henrique Barboza posted 8 patches 3 years, 10 months ago
Test syntax-check failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20200508120657.970343-1-danielhb413@gmail.com
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
[PATCH v1 0/8] Introducing TPM Proxy device support
Posted by Daniel Henrique Barboza 3 years, 10 months ago
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
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

-- 
2.26.2


Re: [PATCH v1 0/8] Introducing TPM Proxy device support
Posted by Stefan Berger 3 years, 10 months ago
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.


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

Re: [PATCH v1 0/8] Introducing TPM Proxy device support
Posted by Daniel Henrique Barboza 3 years, 10 months ago
(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
>>
> 

Re: [PATCH v1 0/8] Introducing TPM Proxy device support
Posted by Stefan Berger 3 years, 10 months ago
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
>>>
>>