QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
implemented by PPC64 guests via a new virtual device called
'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
The TPM Proxy device interacts with a TPM Resource Manager, a host
device capable of multiplexing the host TPM with multiple processes.
This allows multiple guests to access some TPM features at the
same time. Note that this mode of operation does not provide
full TPM features to be available for the guest - for that case
the guest still needs to assign a vTPM device (tpm-spapr for
PPC64 guests). Although redundant, there is currently no technical
limitation for a guest to assign both a vTPM and a TPM Proxy at the
same time.
This patch adds documentation and schema for a new TPM model
type called 'spapr-tpm-proxy' that creates this new TPM Proxy
device. This model is valid only for the 'passthrough' backend.
An example of a TPM Proxy device connected to a TPM Resource Manager
'/dev/tpmrm0' will look like this:
<tpm model='spapr-tpm-proxy'>
<backend type='passthrough'>
<device path='/dev/tpmrm0'/>
</backend>
</tpm>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
---
docs/formatdomain.html.in | 16 +++++++++++++++-
docs/schemas/domaincommon.rng | 1 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 23eb029234..ccbb696058 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -8792,6 +8792,15 @@ qemu-kvm -net nic,model=? /dev/null
backend device is a TPM 2.0. <span class="since">Since 6.1.0</span>,
pSeries guests on PPC64 are supported and the default is
<code>tpm-spapr</code>.
+
+ <span class="since">Since 6.4.0</span>, a new model called
+ <code>spapr-tpm-proxy</code> was added for pSeries guests. This model
+ only works with the 'passthrough' backend. It creates a TPM Proxy
+ device that allows a QEMU guest to interact with an existing TPM Resource
+ Manager in the host, for example /dev/tpmrm0. A TPM Resource Manager
+ enables the host TPM device to be securely multiplexed across
+ several guests. Only one TPM Proxy device is allowed per guest, but
+ a TPM Proxy device can be added together with other TPM devices.
</p>
</dd>
<dt><code>backend</code></dt>
@@ -8804,7 +8813,7 @@ qemu-kvm -net nic,model=? /dev/null
<dt><code>passthrough</code></dt>
<dd>
<p>
- Use the host's TPM device.
+ Use the host's TPM or TPM Resource Manager device.
</p>
<p>
This backend type requires exclusive access to a TPM device on
@@ -8812,6 +8821,11 @@ qemu-kvm -net nic,model=? /dev/null
qualified file name is specified by path attribute of the
<code>source</code> element. If no file name is specified then
/dev/tpm0 is automatically used.
+
+ <span class="since">Since 6.4.0</span>, when choosing the
+ <code>spapr-tpm-proxy</code> model, the file name specified is
+ expected to be a TPM Resource Manager device, e.g.
+ /dev/tpmrm0.
</p>
</dd>
</dl>
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 9d60b090f3..50860419c3 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4610,6 +4610,7 @@
<value>tpm-tis</value>
<value>tpm-crb</value>
<value>tpm-spapr</value>
+ <value>spapr-tpm-proxy</value>
</choice>
</attribute>
</optional>
--
2.26.2
On 5/13/20 10:10 AM, Daniel Henrique Barboza wrote: > QEMU 4.1.0 introduced a new device type called TPM Proxy, currently > implemented by PPC64 guests via a new virtual device called > 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info). > > The TPM Proxy device interacts with a TPM Resource Manager, a host > device capable of multiplexing the host TPM with multiple processes. > This allows multiple guests to access some TPM features at the > same time. Note that this mode of operation does not provide > full TPM features to be available for the guest - for that case > the guest still needs to assign a vTPM device (tpm-spapr for > PPC64 guests). Although redundant, there is currently no technical > limitation for a guest to assign both a vTPM and a TPM Proxy at the > same time. > > This patch adds documentation and schema for a new TPM model > type called 'spapr-tpm-proxy' that creates this new TPM Proxy > device. This model is valid only for the 'passthrough' backend. > An example of a TPM Proxy device connected to a TPM Resource Manager > '/dev/tpmrm0' will look like this: > > <tpm model='spapr-tpm-proxy'> > <backend type='passthrough'> > <device path='/dev/tpmrm0'/> > </backend> > </tpm> > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> > --- > docs/formatdomain.html.in | 16 +++++++++++++++- > docs/schemas/domaincommon.rng | 1 + > 2 files changed, 16 insertions(+), 1 deletion(-) > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index 23eb029234..ccbb696058 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -8792,6 +8792,15 @@ qemu-kvm -net nic,model=? /dev/null > backend device is a TPM 2.0. <span class="since">Since 6.1.0</span>, > pSeries guests on PPC64 are supported and the default is > <code>tpm-spapr</code>. > + > + <span class="since">Since 6.4.0</span>, a new model called > + <code>spapr-tpm-proxy</code> was added for pSeries guests. This model I think you should mention its application is restricted to 'secure VM' here since this seems to be what it is used for. A normal 'pSeries guest' won't make use of it, or would it? > + only works with the 'passthrough' backend. It creates a TPM Proxy > + device that allows a QEMU guest to interact with an existing TPM Resource > + Manager in the host, for example /dev/tpmrm0. A TPM Resource Manager > + enables the host TPM device to be securely multiplexed across > + several guests. Only one TPM Proxy device is allowed per guest, but > + a TPM Proxy device can be added together with other TPM devices. > </p> > </dd> > <dt><code>backend</code></dt> > @@ -8804,7 +8813,7 @@ qemu-kvm -net nic,model=? /dev/null > <dt><code>passthrough</code></dt> > <dd> > <p> > - Use the host's TPM device. > + Use the host's TPM or TPM Resource Manager device. > </p> > <p> > This backend type requires exclusive access to a TPM device on > @@ -8812,6 +8821,11 @@ qemu-kvm -net nic,model=? /dev/null > qualified file name is specified by path attribute of the > <code>source</code> element. If no file name is specified then > /dev/tpm0 is automatically used. > + > + <span class="since">Since 6.4.0</span>, when choosing the > + <code>spapr-tpm-proxy</code> model, the file name specified is > + expected to be a TPM Resource Manager device, e.g. > + /dev/tpmrm0. > </p> > </dd> > </dl> > diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng > index 9d60b090f3..50860419c3 100644 > --- a/docs/schemas/domaincommon.rng > +++ b/docs/schemas/domaincommon.rng > @@ -4610,6 +4610,7 @@ > <value>tpm-tis</value> > <value>tpm-crb</value> > <value>tpm-spapr</value> > + <value>spapr-tpm-proxy</value> > </choice> > </attribute> > </optional>
On 5/13/20 11:28 AM, Stefan Berger wrote:
> On 5/13/20 10:10 AM, Daniel Henrique Barboza wrote:
>> QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
>> implemented by PPC64 guests via a new virtual device called
>> 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
>>
>> The TPM Proxy device interacts with a TPM Resource Manager, a host
>> device capable of multiplexing the host TPM with multiple processes.
>> This allows multiple guests to access some TPM features at the
>> same time. Note that this mode of operation does not provide
>> full TPM features to be available for the guest - for that case
>> the guest still needs to assign a vTPM device (tpm-spapr for
>> PPC64 guests). Although redundant, there is currently no technical
>> limitation for a guest to assign both a vTPM and a TPM Proxy at the
>> same time.
>>
>> This patch adds documentation and schema for a new TPM model
>> type called 'spapr-tpm-proxy' that creates this new TPM Proxy
>> device. This model is valid only for the 'passthrough' backend.
>> An example of a TPM Proxy device connected to a TPM Resource Manager
>> '/dev/tpmrm0' will look like this:
>>
>> <tpm model='spapr-tpm-proxy'>
>> <backend type='passthrough'>
>> <device path='/dev/tpmrm0'/>
>> </backend>
>> </tpm>
>>
>> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>> ---
>> docs/formatdomain.html.in | 16 +++++++++++++++-
>> docs/schemas/domaincommon.rng | 1 +
>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>> index 23eb029234..ccbb696058 100644
>> --- a/docs/formatdomain.html.in
>> +++ b/docs/formatdomain.html.in
>> @@ -8792,6 +8792,15 @@ qemu-kvm -net nic,model=? /dev/null
>> backend device is a TPM 2.0. <span class="since">Since 6.1.0</span>,
>> pSeries guests on PPC64 are supported and the default is
>> <code>tpm-spapr</code>.
>> +
>> + <span class="since">Since 6.4.0</span>, a new model called
>> + <code>spapr-tpm-proxy</code> was added for pSeries guests. This model
>
>
> I think you should mention its application is restricted to 'secure VM' here since this seems to be what it is used for. A normal 'pSeries guest' won't make use of it, or would it?
What about this:
<span class="since">Since 6.4.0</span>, a new model called
<code>spapr-tpm-proxy</code> was added for pSeries guests. This model
only works with the 'passthrough' backend. It creates a TPM Proxy
device that communicates with an existing TPM Resource Manager
in the host, for example /dev/tpmrm0, to enable secure VM support for
the guest. Only one TPM Proxy device is allowed per guest, but a TPM Proxy
device can be added together with other TPM devices.
I cut down the bit about what the TPM Resource Manager does to emphasize the intended
use of the device.
Thanks,
DHB
On 5/13/20 11:30 AM, Daniel Henrique Barboza wrote: > > > On 5/13/20 11:28 AM, Stefan Berger wrote: >> On 5/13/20 10:10 AM, Daniel Henrique Barboza wrote: >>> QEMU 4.1.0 introduced a new device type called TPM Proxy, currently >>> implemented by PPC64 guests via a new virtual device called >>> 'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info). >>> >>> The TPM Proxy device interacts with a TPM Resource Manager, a host >>> device capable of multiplexing the host TPM with multiple processes. >>> This allows multiple guests to access some TPM features at the >>> same time. Note that this mode of operation does not provide >>> full TPM features to be available for the guest - for that case >>> the guest still needs to assign a vTPM device (tpm-spapr for >>> PPC64 guests). Although redundant, there is currently no technical >>> limitation for a guest to assign both a vTPM and a TPM Proxy at the >>> same time. >>> >>> This patch adds documentation and schema for a new TPM model >>> type called 'spapr-tpm-proxy' that creates this new TPM Proxy >>> device. This model is valid only for the 'passthrough' backend. >>> An example of a TPM Proxy device connected to a TPM Resource Manager >>> '/dev/tpmrm0' will look like this: >>> >>> <tpm model='spapr-tpm-proxy'> >>> <backend type='passthrough'> >>> <device path='/dev/tpmrm0'/> >>> </backend> >>> </tpm> >>> >>> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> >>> --- >>> docs/formatdomain.html.in | 16 +++++++++++++++- >>> docs/schemas/domaincommon.rng | 1 + >>> 2 files changed, 16 insertions(+), 1 deletion(-) >>> >>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in >>> index 23eb029234..ccbb696058 100644 >>> --- a/docs/formatdomain.html.in >>> +++ b/docs/formatdomain.html.in >>> @@ -8792,6 +8792,15 @@ qemu-kvm -net nic,model=? /dev/null >>> backend device is a TPM 2.0. <span class="since">Since >>> 6.1.0</span>, >>> pSeries guests on PPC64 are supported and the default is >>> <code>tpm-spapr</code>. >>> + >>> + <span class="since">Since 6.4.0</span>, a new model called >>> + <code>spapr-tpm-proxy</code> was added for pSeries >>> guests. This model >> >> >> I think you should mention its application is restricted to 'secure >> VM' here since this seems to be what it is used for. A normal >> 'pSeries guest' won't make use of it, or would it? > > > What about this: > > > <span class="since">Since 6.4.0</span>, a new model called > <code>spapr-tpm-proxy</code> was added for pSeries guests. > This model > only works with the 'passthrough' backend. It creates a TPM > Proxy > device that communicates with an existing TPM Resource Manager > in the host, for example /dev/tpmrm0, to enable secure VM > support for > the guest. Only one TPM Proxy device is allowed per guest, > but a TPM Proxy > device can be added together with other TPM devices. > > > > I cut down the bit about what the TPM Resource Manager does to > emphasize the intended > use of the device. I think users need to understand that a pSeries guest will not benefit from this but only a pSeries guest that is a secure virtual machine that needs special hardware to run and where there is an Ultravisor. Everyone would want more security for their pSeries guest, especially if it comes for free. Unfortunately this is not the case and one needs new hardware... > > > Thanks, > > > DHB
On 5/13/20 12:45 PM, Stefan Berger wrote:
[...]
>
> I think users need to understand that a pSeries guest will not benefit from this but only a pSeries guest that is a secure virtual machine that needs special hardware to run and where there is an Ultravisor. Everyone would want more security for their pSeries guest, especially if it comes for free. Unfortunately this is not the case and one needs new hardware...
>
True. I propose this wording:
<span class="since">Since 6.4.0</span>, a new model called
<code>spapr-tpm-proxy</code> was added for pSeries guests. This model
only works with the 'passthrough' backend. It creates a TPM Proxy
device that communicates with an existing TPM Resource Manager in the host,
for example /dev/tpmrm0, to enable secure virtual machine support for the
guest with the help of an Ultravisor. Adding a TPM Proxy to a pSeries guest
brings no security benefits unless the guest is running in a PPC64 host that
has Ultravisor support and access to a TPM Resource Manager. Only one TPM
Proxy device is allowed per guest, but a TPM Proxy device can be added together
with other TPM devices.
If you agree, I'll use a similar text in the news.xml changes (patch 8/8) as well.
Thanks,
DHB
>
>>
>>
>> Thanks,
>>
>>
>> DHB
>
>
On 5/13/20 12:49 PM, Daniel Henrique Barboza wrote: > > > On 5/13/20 12:45 PM, Stefan Berger wrote: > [...] >> >> I think users need to understand that a pSeries guest will not >> benefit from this but only a pSeries guest that is a secure virtual >> machine that needs special hardware to run and where there is an >> Ultravisor. Everyone would want more security for their pSeries >> guest, especially if it comes for free. Unfortunately this is not the >> case and one needs new hardware... >> > > True. I propose this wording: > > <span class="since">Since 6.4.0</span>, a new model called > <code>spapr-tpm-proxy</code> was added for pSeries guests. > This model > only works with the 'passthrough' backend. It creates a TPM > Proxy > device that communicates with an existing TPM Resource > Manager in the host, > for example /dev/tpmrm0, to enable secure virtual machine > support for the > guest with the help of an Ultravisor. Adding a TPM Proxy to > a pSeries guest > brings no security benefits unless the guest is running in a > PPC64 host that in -> on > > has Ultravisor support and access to a TPM Resource Manager. > Only one TPM > Proxy device is allowed per guest, but a TPM Proxy device > can be added together > with other TPM devices. > > > If you agree, I'll use a similar text in the news.xml changes (patch > 8/8) as well. I would agree to this. > > > Thanks, > > > DHB > > >> >>> >>> >>> Thanks, >>> >>> >>> DHB >> >>
© 2016 - 2024 Red Hat, Inc.