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

On Sat, Sep 28, 2024 at 12:33:37PM -0400, Stefan Berger wrote: > > > 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? The "post parse" callbacks can be used to fill-in defaults in the XML after parsing. >>>> 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. What's the rational for special casing this to not allow the 'default-vNN' profiles to be modified ? This special case makes it more difficult and

error prone to consume this, as there's no guarantee that the 'default' profiles will be usable wrt host crypto policies.