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

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