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