-
Notifications
You must be signed in to change notification settings - Fork 144
Open and Resolved Issues
-
Windows BitLocker requesting recovery password after upgrade of QEMU from 5.1 to 5.2: unlikely an issue related to swtpm or libtpms in the reported case but may be related to changes in PCR values due to measurements; also see this page here
-
The tcsd (TrouSerS) package fails to install on Ubuntu on a system where
/dev/tpm0
is a TPM 2; it works fine if /dev/tpm0 is missing due to no TPM on the system; To have the issue resolved, the following bug report has been filed with Debian/Ubuntu: https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/1802133- We need tcsd as part of swtpm-tools to be able to support virtualizing a TPM 1.2
- Also see issue 88: https://github.com/stefanberger/swtpm/issues/88
-
tpmtool
is not packaged by Ubuntu as part of GnuTLS package- Using the host's TPM 1.2 as a CA will not work
- Resolved with this patch.
Related issue with libvirt 7.5 and earlier: swtpm v0.7.0 and later does not work properly on Ubuntu system. The reason is that libvirt needs to have its swtpm AppArmor policy updated with this patch. Error messages like this one appear in the VM:
[ 1.392901] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1)
[ 1.395489] tpm tpm0: A TPM error (257) occurred attempting the self test00001 BXPC 00000001)
[ 1.398182] tpm tpm0: A TPM error (257) occurred attempting the self test
The swtpm log (/var/log/swtpm/libvirt/qemu/<vm name>-swtpm.log
) shows errors like this one:
SWTPM_NVRAM_StoreData: Error (fatal) opening /var/lib/libvirt/swtpm/7cf29f14-a170-4e33-bece-1f1e4c7e10b7/tpm2 for
fsync failed, Permission denied
libtpms/tpm2: Entering failure mode; code: 3, location: ExecuteCommand line 308
libtpms/tpm2: TPM2_Process: Entered failure mode through command:
80 01 00 00 00 0c 00 00 01 44 00 00
The reason for this failure is that the AppArmor policy denies the opening the directory for read-only to then be able to do fsync() on it.
- libvirt migration issue with an attached vTPM in libvirt v6.10.0 and 7.0.0 due to this patch. It's been resolve with this patch here. VM migration may fail with complaints like this since SELinux labels could not be removed on the target host upon VM teardown when the VM was there previously:
error: Requested operation is not valid: Setting different SELinux label on /var/lib/libvirt/swtpm/ecc.../tpm2/.lock which is already in use
-
Related issue: Measured boot with UEFI/EDk2 in a QEMU VM is not working in Linux 5.9 .. 5.12.1 due to a kernel bug in drivers/char/tpm/eventlog/acpi.c. Resolved in 5.10.36, 5.11.20, 5.12.3; remains broken in 5.9.x.
-
Signing with pkcs11 keys does not finish / work and when running
p11-tool --list-tokens
as a non-root user we get pop up windows to authenticate with PC/SC daemon. The easiest solution seems to be to turn the PC/SC daemon off:sudo systemctl disable pcsdc; sudo systemctl stop pcsdc
-
On some distros the starting of a VM with an attached vTPM 1.2 does not work even though tcsd is installed; this is (often) related to how tcsd is configured and what ownership requirements it has on the tcsd config file (check:
tcsd -c /tmp/foo -f
) and requires./configure [] --with-tss-user=<user> --with-tss-group=<group>
to use the proper user and group that tcsd expected along with similar configuration of libvirt (/etc/libvirt/qemu.conf swtpm_user and swtpm_group entries); the bugs in swtpm_setup were fixed in libtpms >0.3.2; swtpm_setup >= 0.4 does not use tcsd anymore -
The Ubuntu 16.04 and 20.04 x86_64 (not ppc64le, arm*, i386, s390) PPA build servers fail the test suite due to 'bad system call' errors by 'swtpm'. This is likely due to the seccomp profile or the seccomp libary. The solution there is to run the test suite using
SWTPM_TEST_SECCOMP_OPT="--seccomp action=none" make -j4 check VERBOSE=1
-
Older versions of the TPM 1.2 NVRAM tpm-tools are not working correctly, which results in failures in the
test_parameters
test case Test 15. The bug has been fixed in recent versions of the tpm-tools package. -
Some versions of the gnutls tools (gnutls-utils-3.6.3-2.fc28.x86_64) cannot read ECC public keys, which causes a failure of the
test_tpm2_swtpm_cert_ecc
test case. This has been fixed in gnutls (Bug Report). -
Older versions of the Intel and IBM TSS 2 cannot deal with more than 3 PCR banks, even though only 2 banks are enabled. The reason is that the TSS stacks did not support TPM 2 messages reporting about more than 3 PCR banks. Both TSS 2 stacks have been extended to support this, though. The Intel TSS 2 on Fedora (f28: tpm-tools-3.0.4-1, f26: tpm2-tools-2.1.1-1, tpm2-tss-1.2.0-1) doesn't seem to have this problem.
-
Gnutls 3.6.5 starts supporting --srk-well-known in tpmtool, otherwise it is impossible to create a key if the TPM 1.2 has the well known password of 20 zero bytes.