On 9/30/24 5:52 AM, Marc-André Lureau wrote:
Hi On Thu, Sep 26, 2024 at 11:32 PM Stefan Berger <stefanb@xxxxxxxxxxxxx> wrote:Upcoming libtpms v0.10 and swtpm v0.10 will have TPM profile support that allows to restrict a TPM's provided set of crypto algorithms and commands and through which backwards compatibility and migration from newer versions of libtpms to older ones (up to libtpms v0.9) is supported. For the latter to work it is necessary that the user chooses the right ('null') profile. This series adds support for passing a profile choice to swtpm_setup by setting it in the domain XML using the <profile/> XML node. An optional attribute 'remove_disabled' can be set in this node and accepts two values: "check": test a few crypto algorithms (tdes, camellia, unpadded encryption, and others) for whether they are currently disabled due to FIPS mode on the host and remove these algorithms in the 'custom' profile if they are disabled;Given that this option can expose a different vTPM to the guest, I wonder if it should be in the libvirt XML.
You mean different vTPM because of the changes it can make to the profile? [ It will make different changes to the profile depending on OS. Fedora, CentOS, and RHEL are **at the moment** all slightly different per this page here: https://trustedcomputinggroup.org/wp-content/uploads/TCG-FIPS-140-3-Guidance-for-TPM-2.0-Version-1.0-Revision-1_14Feb24.pdf ]
So if no "remove_disabled" option is given, no check and removal is performed? there should probably be a third option then. "none" ?"fips-host": do not test but remove all the possibly disabled crypto algorithms (from list above)This one however feels safer to expose. I'd suggest a simpler naming too: disable_crypto=none/fips ?
The problem with naming it 'fips' is that FIPS can be quite a lot more in relation to TPM and required extensions to profiles: - https://trustedcomputinggroup.org/wp-content/uploads/TCG-FIPS-140-3-Guidance-for-TPM-2.0-Version-1.0-Revision-1_14Feb24.pdf
- https://github.com/stefanberger/libtpms/pull/428
Also extend the documentation but point the user to swtpm and libtpms documentation for further details. Follow Deniel's suggestions there's now a PR for swtpm_setup to support searching for profiles though a configurable local directory, distro directory and if no profile could be found there (with appended ".json" suffix) it will fall back to try to use a built-in profile by the provided name: https://github.com/stefanberger/swtpm/pull/918 Stefan Stefan Berger (8): conf: Move TPM emulator parameters into own struct qemu: Pass virQEMUDriverConfig rather than some of its fields util: Add parsing support for swtpm_setup's cmdarg-profile capability conf: Define enum virDomainTPMProfileRemoveDisabled schema: Extend schema for TPM emulator profile node conf: Add support for profile parameter on TPM emulator in domain XML docs: Add documentation for the TPM backend profile node qemu: Extend swtpm_setup command line to set a profile by its name docs/formatdomain.rst | 30 ++++++++ src/conf/domain_conf.c | 43 +++++++++++ src/conf/domain_conf.h | 35 ++++++--- src/conf/domain_validate.c | 7 ++ src/conf/schemas/domaincommon.rng | 25 ++++++ src/conf/virconftypes.h | 2 + src/qemu/qemu_tpm.c | 124 +++++++++++++++++------------- src/util/virtpm.c | 1 + src/util/virtpm.h | 1 + tests/testutilsqemu.c | 1 + 10 files changed, 203 insertions(+), 66 deletions(-) -- 2.46.1
