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