Add documentation for the TPM backend profile node and point the reader to
further documentation about TPM profiles available in the swtpm and
TPMLIB_SetProfile man pages.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 4336cff3ac..fe6230f39b 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator
<active_pcr_banks>
<sha256/>
</active_pcr_banks>
+ <profile name='local:restricted' remove_disabled='check'/>
</backend>
</tpm>
</devices>
@@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator
and may not have any effect otherwise. The selection of PCR banks only works
with the ``emulator`` backend. :since:`Since 7.10.0`
+``profile``
+ The ``profile`` node is used to set a profile for a TPM 2.0. This profile
+ will be set when the TPM is initially created and after that cannot be
+ changed anymore. If no profile is provided, then swtpm will use the latest
+ built-in 'default' profile or the default profile set in swtpm_setup.conf.
+ Otherwise swtpm_setup will search for a profile with the given name with
+ appended .json suffix in a configurable local and then in a distro
+ directory. If none could be found in either, it will fall back trying to
+ use a built-in one.
+
+ The built-in 'null' profile provides backwards compatibility with
+ libtpms v0.9 but also restricts the user to use only TPM features that were
+ available at the time of libtpms v0.9. The built-in 'custom' profile is the
+ only profile that a user can modify and where the ``remove_disabled``
+ attribute has any effect. This attribute is particularly useful when a host
+ is running in FIPS mode and therefore some crypto algorithms (camellia,
+ tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are
+ disabled. When it is set to ``check`` (recommended) then only those
+ algorithms that are currently disabled will automatically be removed from
+ the 'custom' profile, while when it is set to ``fips-host`` then all
+ potentially disabled algorithms will be removed. :since:`Since 10.??.0`
+
+ TPM profiles provided by a distro can be referenced with the 'distro'
+ attribute. Locally created TPM profiles can be referenced with the
+ 'local' attribute.
+
+ For further information about TPM profiles see the man pages for ``swtpm``
+ (swtpm v0.10) and libtpms's ``TPMLIB_SetProfile`` (libtpms v0.10).
+
``encryption``
The ``encryption`` element allows the state of a TPM emulator to be
encrypted. The ``secret`` must reference a secret object that holds the
--
2.46.1On Thu, Sep 26, 2024 at 03:32:07PM -0400, Stefan Berger wrote: > Add documentation for the TPM backend profile node and point the reader to > further documentation about TPM profiles available in the swtpm and > TPMLIB_SetProfile man pages. > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> > --- > docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > index 4336cff3ac..fe6230f39b 100644 > --- a/docs/formatdomain.rst > +++ b/docs/formatdomain.rst > @@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator > <active_pcr_banks> > <sha256/> > </active_pcr_banks> > + <profile name='local:restricted' remove_disabled='check'/> > </backend> > </tpm> > </devices> > @@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator > and may not have any effect otherwise. The selection of PCR banks only works > with the ``emulator`` backend. :since:`Since 7.10.0` > > +``profile`` > + The ``profile`` node is used to set a profile for a TPM 2.0. This profile > + will be set when the TPM is initially created and after that cannot be > + changed anymore. If no profile is provided, then swtpm will use the latest > + built-in 'default' profile or the default profile set in swtpm_setup.conf. Am I right that "profile" name only used on the first boot, at the time of manufacturing ? IOW, if we later live migrate to a new host with different default profile the guest will still use the original manufactured profile. In any case, I think if no profile is set, then we should fill in the XML to record the profile that we manufactured. This will allow an admin to look at the guest XML later and identify any guests manufactured with potentially outdated profiles. > + Otherwise swtpm_setup will search for a profile with the given name with > + appended .json suffix in a configurable local and then in a distro > + directory. If none could be found in either, it will fall back trying to > + use a built-in one. > + > + The built-in 'null' profile provides backwards compatibility with > + libtpms v0.9 but also restricts the user to use only TPM features that were > + available at the time of libtpms v0.9. The built-in 'custom' profile is the > + only profile that a user can modify and where the ``remove_disabled`` > + attribute has any effect. This attribute is particularly useful when a host > + is running in FIPS mode and therefore some crypto algorithms (camellia, > + tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are > + disabled. When it is set to ``check`` (recommended) then only those > + algorithms that are currently disabled will automatically be removed from > + the 'custom' profile, while when it is set to ``fips-host`` then all > + potentially disabled algorithms will be removed. :since:`Since 10.??.0` I'm not sure I understand what "custom" means as a profile here ? What defines the set of algs that go into 'custom' profile ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 9/26/24 4:18 PM, Daniel P. Berrangé wrote: > On Thu, Sep 26, 2024 at 03:32:07PM -0400, Stefan Berger wrote: >> Add documentation for the TPM backend profile node and point the reader to >> further documentation about TPM profiles available in the swtpm and >> TPMLIB_SetProfile man pages. >> >> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> >> --- >> docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++ >> 1 file changed, 30 insertions(+) >> >> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst >> index 4336cff3ac..fe6230f39b 100644 >> --- a/docs/formatdomain.rst >> +++ b/docs/formatdomain.rst >> @@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator >> <active_pcr_banks> >> <sha256/> >> </active_pcr_banks> >> + <profile name='local:restricted' remove_disabled='check'/> >> </backend> >> </tpm> >> </devices> >> @@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator >> and may not have any effect otherwise. The selection of PCR banks only works >> with the ``emulator`` backend. :since:`Since 7.10.0` >> >> +``profile`` >> + The ``profile`` node is used to set a profile for a TPM 2.0. This profile >> + will be set when the TPM is initially created and after that cannot be >> + changed anymore. If no profile is provided, then swtpm will use the latest >> + built-in 'default' profile or the default profile set in swtpm_setup.conf. > > Am I right that "profile" name only used on the first boot, at the time of > manufacturing ? > > IOW, if we later live migrate to a new host with different default profile > the guest will still use the original manufactured profile. Correct. You cannot gain access to new crypto algorithms and you cannot loose them either when migrating. In the worst case the migration will be rejected because you had access to a crypto algo (which you presumably also used because it is enabled in the profile) and the libtpms on the target machine does not support this yet because it is an older verson. It wouldn't be helpful to take away access to some crypto algo that an application/kernel driver relies on when migrating to another host and now the decryption of data doesn't work anymore. The whole problem wouldn't exist if TPM 2 development had ended but it hasn't ended. Next I would expect PQ-crypto to be added to TPM 2s. > > In any case, I think if no profile is set, then we should fill in the XML > to record the profile that we manufactured. This will allow an admin to For detecting which profile was actually set we would have to look at the VM's swtpm log file where that is reflected -- or start swtpm and query its control channel. The custom profile can be changed quite a bit by reducing the Commands and Algorithms and setting Attributes. You would have to really record the whole JSON profile -- and that's logged in the swtpm log. > look at the guest XML later and identify any guests manufactured with > potentially outdated profiles. > >> + Otherwise swtpm_setup will search for a profile with the given name with >> + appended .json suffix in a configurable local and then in a distro >> + directory. If none could be found in either, it will fall back trying to >> + use a built-in one. >> + >> + The built-in 'null' profile provides backwards compatibility with >> + libtpms v0.9 but also restricts the user to use only TPM features that were >> + available at the time of libtpms v0.9. The built-in 'custom' profile is the >> + only profile that a user can modify and where the ``remove_disabled`` >> + attribute has any effect. This attribute is particularly useful when a host >> + is running in FIPS mode and therefore some crypto algorithms (camellia, >> + tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are >> + disabled. When it is set to ``check`` (recommended) then only those >> + algorithms that are currently disabled will automatically be removed from >> + the 'custom' profile, while when it is set to ``fips-host`` then all >> + potentially disabled algorithms will be removed. :since:`Since 10.??.0` > > I'm not sure I understand what "custom" means as a profile here ? What > defines the set of algs that go into 'custom' profile ? > > > > With regards, > Daniel
On Thu, Sep 26, 2024 at 04:44:28PM -0400, Stefan Berger wrote: > > > On 9/26/24 4:18 PM, Daniel P. Berrangé wrote: > > On Thu, Sep 26, 2024 at 03:32:07PM -0400, Stefan Berger wrote: > > > Add documentation for the TPM backend profile node and point the reader to > > > further documentation about TPM profiles available in the swtpm and > > > TPMLIB_SetProfile man pages. > > > > > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> > > > --- > > > docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++ > > > 1 file changed, 30 insertions(+) > > > > > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > > > index 4336cff3ac..fe6230f39b 100644 > > > --- a/docs/formatdomain.rst > > > +++ b/docs/formatdomain.rst > > > @@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator > > > <active_pcr_banks> > > > <sha256/> > > > </active_pcr_banks> > > > + <profile name='local:restricted' remove_disabled='check'/> > > > </backend> > > > </tpm> > > > </devices> > > > @@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator > > > and may not have any effect otherwise. The selection of PCR banks only works > > > with the ``emulator`` backend. :since:`Since 7.10.0` > > > +``profile`` > > > + The ``profile`` node is used to set a profile for a TPM 2.0. This profile > > > + will be set when the TPM is initially created and after that cannot be > > > + changed anymore. If no profile is provided, then swtpm will use the latest > > > + built-in 'default' profile or the default profile set in swtpm_setup.conf. > > > > Am I right that "profile" name only used on the first boot, at the time of > > manufacturing ? > > > > IOW, if we later live migrate to a new host with different default profile > > the guest will still use the original manufactured profile. > > Correct. You cannot gain access to new crypto algorithms and you cannot > loose them either when migrating. In the worst case the migration will be > rejected because you had access to a crypto algo (which you presumably also > used because it is enabled in the profile) and the libtpms on the target > machine does not support this yet because it is an older verson. It wouldn't > be helpful to take away access to some crypto algo that an > application/kernel driver relies on when migrating to another host and now > the decryption of data doesn't work anymore. The whole problem wouldn't > exist if TPM 2 development had ended but it hasn't ended. Next I would > expect PQ-crypto to be added to TPM 2s. > > > > > In any case, I think if no profile is set, then we should fill in the XML > > to record the profile that we manufactured. This will allow an admin to > > For detecting which profile was actually set we would have to look at the > VM's swtpm log file where that is reflected -- or start swtpm and query its > control channel. > > The custom profile can be changed quite a bit by reducing the Commands and > Algorithms and setting Attributes. You would have to really record the whole > JSON profile -- and that's logged in the swtpm log. I wasn't really thinking about that level of detail, rather the more mundane level of whether the vTPM was created with 'default-v1' or 'default-v2' or 'default-v3', etc. Recording the default profile in the XML exposes this otherwise hidden info. > > look at the guest XML later and identify any guests manufactured with > > potentially outdated profiles. > > > > > + Otherwise swtpm_setup will search for a profile with the given name with > > > + appended .json suffix in a configurable local and then in a distro > > > + directory. If none could be found in either, it will fall back trying to > > > + use a built-in one. > > > + > > > + The built-in 'null' profile provides backwards compatibility with > > > + libtpms v0.9 but also restricts the user to use only TPM features that were > > > + available at the time of libtpms v0.9. The built-in 'custom' profile is the > > > + only profile that a user can modify and where the ``remove_disabled`` > > > + attribute has any effect. This attribute is particularly useful when a host > > > + is running in FIPS mode and therefore some crypto algorithms (camellia, > > > + tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are > > > + disabled. When it is set to ``check`` (recommended) then only those > > > + algorithms that are currently disabled will automatically be removed from > > > + the 'custom' profile, while when it is set to ``fips-host`` then all > > > + potentially disabled algorithms will be removed. :since:`Since 10.??.0` > > > > I'm not sure I understand what "custom" means as a profile here ? What > > defines the set of algs that go into 'custom' profile ? Why are the 'fips-host' and 'remove_disable' flags limted to the 'custom' profile ? I would think it is valid to want to apply them to the default profiles too, as those give you a clear baseline against which you're removing features. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 9/27/24 1:06 PM, Daniel P. Berrangé wrote:
> On Thu, Sep 26, 2024 at 04:44:28PM -0400, Stefan Berger wrote:
>>
>>
>> On 9/26/24 4:18 PM, Daniel P. Berrangé wrote:
>>> On Thu, Sep 26, 2024 at 03:32:07PM -0400, Stefan Berger wrote:
>>>> Add documentation for the TPM backend profile node and point the reader to
>>>> further documentation about TPM profiles available in the swtpm and
>>>> TPMLIB_SetProfile man pages.
>>>>
>>>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>>>> ---
>>>> docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++
>>>> 1 file changed, 30 insertions(+)
>>>>
>>>> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
>>>> index 4336cff3ac..fe6230f39b 100644
>>>> --- a/docs/formatdomain.rst
>>>> +++ b/docs/formatdomain.rst
>>>> @@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator
>>>> <active_pcr_banks>
>>>> <sha256/>
>>>> </active_pcr_banks>
>>>> + <profile name='local:restricted' remove_disabled='check'/>
>>>> </backend>
>>>> </tpm>
>>>> </devices>
>>>> @@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator
>>>> and may not have any effect otherwise. The selection of PCR banks only works
>>>> with the ``emulator`` backend. :since:`Since 7.10.0`
>>>> +``profile``
>>>> + The ``profile`` node is used to set a profile for a TPM 2.0. This profile
>>>> + will be set when the TPM is initially created and after that cannot be
>>>> + changed anymore. If no profile is provided, then swtpm will use the latest
>>>> + built-in 'default' profile or the default profile set in swtpm_setup.conf.
>>>
>>> Am I right that "profile" name only used on the first boot, at the time of
>>> manufacturing ?
>>>
>>> IOW, if we later live migrate to a new host with different default profile
>>> the guest will still use the original manufactured profile.
>>
>> Correct. You cannot gain access to new crypto algorithms and you cannot
>> loose them either when migrating. In the worst case the migration will be
>> rejected because you had access to a crypto algo (which you presumably also
>> used because it is enabled in the profile) and the libtpms on the target
>> machine does not support this yet because it is an older verson. It wouldn't
>> be helpful to take away access to some crypto algo that an
>> application/kernel driver relies on when migrating to another host and now
>> the decryption of data doesn't work anymore. The whole problem wouldn't
>> exist if TPM 2 development had ended but it hasn't ended. Next I would
>> expect PQ-crypto to be added to TPM 2s.
>>
>>>
>>> In any case, I think if no profile is set, then we should fill in the XML
>>> to record the profile that we manufactured. This will allow an admin to
>>
>> For detecting which profile was actually set we would have to look at the
>> VM's swtpm log file where that is reflected -- or start swtpm and query its
>> control channel.
>>
>> The custom profile can be changed quite a bit by reducing the Commands and
>> Algorithms and setting Attributes. You would have to really record the whole
>> JSON profile -- and that's logged in the swtpm log.
>
> I wasn't really thinking about that level of detail, rather the
> more mundane level of whether the vTPM was created with
> 'default-v1' or 'default-v2' or 'default-v3', etc. Recording
> the default profile in the XML exposes this otherwise hidden
> info.
Then we also need to lock down this part of the XML. I'd have to search
but is there an example that locks down part of the domain XML once it
has been known that a VM has been created?
>
>
>
>>> look at the guest XML later and identify any guests manufactured with
>>> potentially outdated profiles.
>>>
>>>> + Otherwise swtpm_setup will search for a profile with the given name with
>>>> + appended .json suffix in a configurable local and then in a distro
>>>> + directory. If none could be found in either, it will fall back trying to
>>>> + use a built-in one.
>>>> +
>>>> + The built-in 'null' profile provides backwards compatibility with
>>>> + libtpms v0.9 but also restricts the user to use only TPM features that were
>>>> + available at the time of libtpms v0.9. The built-in 'custom' profile is the
>>>> + only profile that a user can modify and where the ``remove_disabled``
>>>> + attribute has any effect. This attribute is particularly useful when a host
>>>> + is running in FIPS mode and therefore some crypto algorithms (camellia,
>>>> + tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are
>>>> + disabled. When it is set to ``check`` (recommended) then only those
>>>> + algorithms that are currently disabled will automatically be removed from
>>>> + the 'custom' profile, while when it is set to ``fips-host`` then all
>>>> + potentially disabled algorithms will be removed. :since:`Since 10.??.0`
>>>
>>> I'm not sure I understand what "custom" means as a profile here ? What
>>> defines the set of algs that go into 'custom' profile ?
>
> Why are the 'fips-host' and 'remove_disable' flags limted to
> the 'custom' profile ? I would think it is valid to want to
> apply them to the default profiles too, as those give you a
> clear baseline against which you're removing features.
Only the custom profile can be modified, none other. The user can always
make a copy of the default profile, rename it, and have it adjusted by
this option. With profiles being created from the local profiles
directory I think that's something users should be able to do.
Stefan
>
>
> With regards,
> Daniel
On Sat, Sep 28, 2024 at 12:33:37PM -0400, Stefan Berger wrote: > > > On 9/27/24 1:06 PM, Daniel P. Berrangé wrote: > > On Thu, Sep 26, 2024 at 04:44:28PM -0400, Stefan Berger wrote: > > > > > > > > > On 9/26/24 4:18 PM, Daniel P. Berrangé wrote: > > > > On Thu, Sep 26, 2024 at 03:32:07PM -0400, Stefan Berger wrote: > > > > > Add documentation for the TPM backend profile node and point the reader to > > > > > further documentation about TPM profiles available in the swtpm and > > > > > TPMLIB_SetProfile man pages. > > > > > > > > > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> > > > > > --- > > > > > docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++ > > > > > 1 file changed, 30 insertions(+) > > > > > > > > > > diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst > > > > > index 4336cff3ac..fe6230f39b 100644 > > > > > --- a/docs/formatdomain.rst > > > > > +++ b/docs/formatdomain.rst > > > > > @@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator > > > > > <active_pcr_banks> > > > > > <sha256/> > > > > > </active_pcr_banks> > > > > > + <profile name='local:restricted' remove_disabled='check'/> > > > > > </backend> > > > > > </tpm> > > > > > </devices> > > > > > @@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator > > > > > and may not have any effect otherwise. The selection of PCR banks only works > > > > > with the ``emulator`` backend. :since:`Since 7.10.0` > > > > > +``profile`` > > > > > + The ``profile`` node is used to set a profile for a TPM 2.0. This profile > > > > > + will be set when the TPM is initially created and after that cannot be > > > > > + changed anymore. If no profile is provided, then swtpm will use the latest > > > > > + built-in 'default' profile or the default profile set in swtpm_setup.conf. > > > > > > > > Am I right that "profile" name only used on the first boot, at the time of > > > > manufacturing ? > > > > > > > > IOW, if we later live migrate to a new host with different default profile > > > > the guest will still use the original manufactured profile. > > > > > > Correct. You cannot gain access to new crypto algorithms and you cannot > > > loose them either when migrating. In the worst case the migration will be > > > rejected because you had access to a crypto algo (which you presumably also > > > used because it is enabled in the profile) and the libtpms on the target > > > machine does not support this yet because it is an older verson. It wouldn't > > > be helpful to take away access to some crypto algo that an > > > application/kernel driver relies on when migrating to another host and now > > > the decryption of data doesn't work anymore. The whole problem wouldn't > > > exist if TPM 2 development had ended but it hasn't ended. Next I would > > > expect PQ-crypto to be added to TPM 2s. > > > > > > > > > > > In any case, I think if no profile is set, then we should fill in the XML > > > > to record the profile that we manufactured. This will allow an admin to > > > > > > For detecting which profile was actually set we would have to look at the > > > VM's swtpm log file where that is reflected -- or start swtpm and query its > > > control channel. > > > > > > The custom profile can be changed quite a bit by reducing the Commands and > > > Algorithms and setting Attributes. You would have to really record the whole > > > JSON profile -- and that's logged in the swtpm log. > > > > I wasn't really thinking about that level of detail, rather the > > more mundane level of whether the vTPM was created with > > 'default-v1' or 'default-v2' or 'default-v3', etc. Recording > > the default profile in the XML exposes this otherwise hidden > > info. > > Then we also need to lock down this part of the XML. I'd have to search but > is there an example that locks down part of the domain XML once it has been > known that a VM has been created? The "post parse" callbacks can be used to fill-in defaults in the XML after parsing. > > > > look at the guest XML later and identify any guests manufactured with > > > > potentially outdated profiles. > > > > > > > > > + Otherwise swtpm_setup will search for a profile with the given name with > > > > > + appended .json suffix in a configurable local and then in a distro > > > > > + directory. If none could be found in either, it will fall back trying to > > > > > + use a built-in one. > > > > > + > > > > > + The built-in 'null' profile provides backwards compatibility with > > > > > + libtpms v0.9 but also restricts the user to use only TPM features that were > > > > > + available at the time of libtpms v0.9. The built-in 'custom' profile is the > > > > > + only profile that a user can modify and where the ``remove_disabled`` > > > > > + attribute has any effect. This attribute is particularly useful when a host > > > > > + is running in FIPS mode and therefore some crypto algorithms (camellia, > > > > > + tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are > > > > > + disabled. When it is set to ``check`` (recommended) then only those > > > > > + algorithms that are currently disabled will automatically be removed from > > > > > + the 'custom' profile, while when it is set to ``fips-host`` then all > > > > > + potentially disabled algorithms will be removed. :since:`Since 10.??.0` > > > > > > > > I'm not sure I understand what "custom" means as a profile here ? What > > > > defines the set of algs that go into 'custom' profile ? > > > > Why are the 'fips-host' and 'remove_disable' flags limted to > > the 'custom' profile ? I would think it is valid to want to > > apply them to the default profiles too, as those give you a > > clear baseline against which you're removing features. > > Only the custom profile can be modified, none other. The user can always > make a copy of the default profile, rename it, and have it adjusted by this > option. With profiles being created from the local profiles directory I > think that's something users should be able to do. What's the rational for special casing this to not allow the 'default-vNN' profiles to be modified ? This special case makes it more difficult and error prone to consume this, as there's no guarantee that the 'default' profiles will be usable wrt host crypto policies. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 9/30/24 6:04 AM, Daniel P. Berrangé wrote: > On Sat, Sep 28, 2024 at 12:33:37PM -0400, Stefan Berger wrote: >> >> >> On 9/27/24 1:06 PM, Daniel P. Berrangé wrote: >>> On Thu, Sep 26, 2024 at 04:44:28PM -0400, Stefan Berger wrote: >>>> >>>> >>>> On 9/26/24 4:18 PM, Daniel P. Berrangé wrote: >>>>> On Thu, Sep 26, 2024 at 03:32:07PM -0400, Stefan Berger wrote: >>>>>> Add documentation for the TPM backend profile node and point the reader to >>>>>> further documentation about TPM profiles available in the swtpm and >>>>>> TPMLIB_SetProfile man pages. >>>>>> >>>>>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> >>>>>> --- >>>>>> docs/formatdomain.rst | 30 ++++++++++++++++++++++++++++++ >>>>>> 1 file changed, 30 insertions(+) >>>>>> >>>>>> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst >>>>>> index 4336cff3ac..fe6230f39b 100644 >>>>>> --- a/docs/formatdomain.rst >>>>>> +++ b/docs/formatdomain.rst >>>>>> @@ -8119,6 +8119,7 @@ Example: usage of the TPM Emulator >>>>>> <active_pcr_banks> >>>>>> <sha256/> >>>>>> </active_pcr_banks> >>>>>> + <profile name='local:restricted' remove_disabled='check'/> >>>>>> </backend> >>>>>> </tpm> >>>>>> </devices> >>>>>> @@ -8191,6 +8192,35 @@ Example: usage of the TPM Emulator >>>>>> and may not have any effect otherwise. The selection of PCR banks only works >>>>>> with the ``emulator`` backend. :since:`Since 7.10.0` >>>>>> +``profile`` >>>>>> + The ``profile`` node is used to set a profile for a TPM 2.0. This profile >>>>>> + will be set when the TPM is initially created and after that cannot be >>>>>> + changed anymore. If no profile is provided, then swtpm will use the latest >>>>>> + built-in 'default' profile or the default profile set in swtpm_setup.conf. >>>>> >>>>> Am I right that "profile" name only used on the first boot, at the time of >>>>> manufacturing ? >>>>> >>>>> IOW, if we later live migrate to a new host with different default profile >>>>> the guest will still use the original manufactured profile. >>>> >>>> Correct. You cannot gain access to new crypto algorithms and you cannot >>>> loose them either when migrating. In the worst case the migration will be >>>> rejected because you had access to a crypto algo (which you presumably also >>>> used because it is enabled in the profile) and the libtpms on the target >>>> machine does not support this yet because it is an older verson. It wouldn't >>>> be helpful to take away access to some crypto algo that an >>>> application/kernel driver relies on when migrating to another host and now >>>> the decryption of data doesn't work anymore. The whole problem wouldn't >>>> exist if TPM 2 development had ended but it hasn't ended. Next I would >>>> expect PQ-crypto to be added to TPM 2s. >>>> >>>>> >>>>> In any case, I think if no profile is set, then we should fill in the XML >>>>> to record the profile that we manufactured. This will allow an admin to >>>> >>>> For detecting which profile was actually set we would have to look at the >>>> VM's swtpm log file where that is reflected -- or start swtpm and query its >>>> control channel. >>>> >>>> The custom profile can be changed quite a bit by reducing the Commands and >>>> Algorithms and setting Attributes. You would have to really record the whole >>>> JSON profile -- and that's logged in the swtpm log. >>> >>> I wasn't really thinking about that level of detail, rather the >>> more mundane level of whether the vTPM was created with >>> 'default-v1' or 'default-v2' or 'default-v3', etc. Recording >>> the default profile in the XML exposes this otherwise hidden >>> info. >> >> Then we also need to lock down this part of the XML. I'd have to search but >> is there an example that locks down part of the domain XML once it has been >> known that a VM has been created? > > The "post parse" callbacks can be used to fill-in defaults in the XML > after parsing. > >>>>> look at the guest XML later and identify any guests manufactured with >>>>> potentially outdated profiles. >>>>> >>>>>> + Otherwise swtpm_setup will search for a profile with the given name with >>>>>> + appended .json suffix in a configurable local and then in a distro >>>>>> + directory. If none could be found in either, it will fall back trying to >>>>>> + use a built-in one. >>>>>> + >>>>>> + The built-in 'null' profile provides backwards compatibility with >>>>>> + libtpms v0.9 but also restricts the user to use only TPM features that were >>>>>> + available at the time of libtpms v0.9. The built-in 'custom' profile is the >>>>>> + only profile that a user can modify and where the ``remove_disabled`` >>>>>> + attribute has any effect. This attribute is particularly useful when a host >>>>>> + is running in FIPS mode and therefore some crypto algorithms (camellia, >>>>>> + tdes, unpadded RSA encryption, 1024-bit RSA keys, and others) are >>>>>> + disabled. When it is set to ``check`` (recommended) then only those >>>>>> + algorithms that are currently disabled will automatically be removed from >>>>>> + the 'custom' profile, while when it is set to ``fips-host`` then all >>>>>> + potentially disabled algorithms will be removed. :since:`Since 10.??.0` >>>>> >>>>> I'm not sure I understand what "custom" means as a profile here ? What >>>>> defines the set of algs that go into 'custom' profile ? >>> >>> Why are the 'fips-host' and 'remove_disable' flags limted to >>> the 'custom' profile ? I would think it is valid to want to >>> apply them to the default profiles too, as those give you a >>> clear baseline against which you're removing features. >> >> Only the custom profile can be modified, none other. The user can always >> make a copy of the default profile, rename it, and have it adjusted by this >> option. With profiles being created from the local profiles directory I >> think that's something users should be able to do. > > What's the rational for special casing this to not allow the 'default-vNN' > profiles to be modified ? This special case makes it more difficult and I would like to have the default-vNN profiles be known constant profiles that enable all algorithms by default, similar to what TPM 2 does today. Users may then make modifications to profiles with either name 'custom' or 'custom:' prefix in the name. > error prone to consume this, as there's no guarantee that the 'default' > profiles will be usable wrt host crypto policies. > > With regards, > Daniel
© 2016 - 2026 Red Hat, Inc.