Re: [RFC PATCH v2 7/8] docs: Add documentation for the TPM backend profile node

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(a)linux.ibm.com&gt; >>> --- >>> 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.