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@xxxxxxxxxxxxx> > --- > 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 :|
