On 9/30/24 6:04 AM, Daniel P. Berrangé wrote:
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@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.
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
I would like to have the default-vNN profiles be known constant profiles
that enable all algorithms by default, similar to what TPM 2 does today.
Users may then make modifications to profiles with either name 'custom'
or 'custom:' prefix in the name.
error prone to consume this, as there's no guarantee that the 'default'
profiles will be usable wrt host crypto policies.
With regards,
Daniel
