Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Downstream qemu-kvm does not support the TPM configuration for pass-through devices.
Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-105.el7_2.3.x86_64
How reproducible:
Steps to Reproduce:
On RHEL 7.2
1. For KVM guest define a TPM passthrough device as per
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Manipulating_the_domain_xml-Devices.html#sect-Devices-TPM_devices
2. Snip of gues XML definition
---
<tpm model='tpm-tis'>
<backend type='passthrough'>
<device path='/dev/tpm0'/>
</backend> </tpm>
---
3. Start the guest.
Actual results:
Guest fails to start with bellow error:
...
Error starting domain: unsupported configuration: The QEMU executable /usr/libexec/qemu-kvm does not support TPM backend type passthrough
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1433, in startup
self._backend.create()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1029, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unsupported configuration: The QEMU executable /usr/libexec/qemu-kvm does not support TPM backend type passthrough
...
Expected results:
Guest should start normally.
Additional info:
On RHEL 7.2
# rpm -q qemu-kvm
qemu-kvm-1.5.3-105.el7_2.3.x86_64
# /usr/libexec/qemu-kvm --help | grep -i tpm
<no output>
On Fedora 23
# rpm -q qemu-kvm
qemu-kvm-2.4.1-8.fc23.x86_64
# /usr/bin/qemu-kvm --help | grep -i tpm
TPM device options: -tpmdev passthrough,id=id[,path=path][,cancel-path=path]
use path to provide path to a character device; default is /dev/tpm0
use cancel-path to provide path to TPM's cancel sysfs entry;
if not provided it will be searched for in /sys/class/misc/tpm?/device
Installed tpl-tools package.
# ls -al /lib/modules/$(uname -r)/kernel/drivers/char/tpm
total 128
drwxr-xr-x. 2 root root 4096 Apr 2 16:08 .
drwxr-xr-x. 5 root root 4096 Apr 2 16:08 ..
-rw-r--r--. 1 root root 11241 Mar 1 03:55 tpm_atmel.ko
-rw-r--r--. 1 root root 12097 Mar 1 03:55 tpm_crb.ko
-rw-r--r--. 1 root root 11793 Mar 1 03:55 tpm_i2c_atmel.ko
-rw-r--r--. 1 root root 16121 Mar 1 03:55 tpm_i2c_infineon.ko
-rw-r--r--. 1 root root 21857 Mar 1 03:55 tpm_i2c_nuvoton.ko
-rw-r--r--. 1 root root 25225 Mar 1 03:55 tpm_infineon.ko
-rw-r--r--. 1 root root 15969 Mar 1 03:55 tpm_nsc.ko
# tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.6.40
Spec Level: 2
Errata Revision: 3
TPM Vendor ID: IFX
Vendor Specific data: 062800be 0074706d 733038ff ff
TPM Version: 01010000
Manufacturer Info: 49465800
Updated information:
The TPM2 userspace tools as of RHEL 7.5 (Tech Preview in RHEL 7.4) include a resource manager that allows multiple users to interact with a TPM. Multiple keys and key hierarchies can be used. The actual keys are stored on disk as encrypted blobs and loaded and unloaded as needed.
It should be possible to design and implement qemu support such that each VM appears to have its own TPM, including unique set of keys and measurements.
This is not a straight TPM passthrough for the physical TPM, but would meet the requirements for multiple guests using bitlocker and measured boot.
Is this direction worth exploring?