View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006931 | Rocky-Linux-9 | openssl | public | 2024-05-30 18:11 | 2024-06-19 14:37 |
Reporter | Daniel Henninger | Assigned To | Louis Abel | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | needinfo | Resolution | open | ||
Platform | x86_64 | OS | Rocky Linux | OS Version | 9 |
Summary | 0006931: openssl 3.0.7 causing problems with VMs under ovirt that use swtpm | ||||
Description | Hi folk, I've been working with the swtpm developer to track down a bug I was running into while running oVirt (4.5.6) under Rocky Linux 9, and running a Windows 11 guest. You can find that issue here: https://github.com/stefanberger/swtpm/issues/852 Strangely, Windows 11 was able to see the TPM enough to be happy with it for an install, and show the TPM as healthy, but when a command to determine what features it provided was run, it would cause a system error and return nothing. After much delving, and a cue from the swtpm developer, I upgraded openssl from 3.0.7 to fedora 37's 3.0.9 and the problem immediately went away. Unfortunately I do not know the specifics of WHY this would be the source of the problem. As an aside -- the developer noted that libtpms is quite old and there are a number of CVE fixes that have been applied since, and recommended updating that as well. | ||||
Steps To Reproduce | 1. Set up ovirt 4.5.6 (you could probably accomplish this with something lower level but ovirt is what I know best atm) 2. Install a Windows 11 VM under ovirt (if you use the windows 11 OS profile, it will automatically enable TPM support) 3. Fire up a powershell prompt in the Windows 11 VM and run: Get-TPMSupportedFeature 4. Note that it returns nothing -- and you should check the event viewer -> System logs and you will see a TPM error | ||||
Additional Information | The host is running Rocky Linux 9.4, fully up to date as of last friday. Please let me know if you need me to provide additional information. | ||||
Tags | No tags attached. | ||||
Thank you for the report. As you know, we are a derivative of RHEL. This means we cannot make changes nor make upgrades to our packages as it would make us incompatible with our upstream. What I would do is recreate your issue on RHEL 9.4 and submit an issue to https://issues.redhat.com. With that said, CentOS Stream 9 upgrades openssl to 3.2.1. However, that upgrade will not arrive until 9.5. If it is found that the issue is not reproducible in RHEL, then we can attempt to track down where the issue is in our builds to fix the issue. |
|
Hi Louis, sounds like a plan -- I will take it up to Red Hat's issue tracker. Thanks! | |
Sigh.. might be a bit. somehow I have messed up my login at redhat.com. | |
Done: https://issues.redhat.com/browse/RHEL-39899 | |
Hello! I think you can consider this resolved as a "nothing to do" -- it turns out it's as simple as, to quote the reply from Red Hat: Can you try with 3.0.7 and 3.2.2 with the SHA1 crypto-policy module? I'm guessing swtpm may be requiring a signature with SHA-1, which does not work by default on RHEL 9 and up, but does work by default in the Fedora builds. Run update-crypto-policies --set DEFAULT:SHA1 to switch to that. Even 3.0.7 works just fine with this setting. As an aside -- RHEL 9.5 is coming with openssl 3.2.2 (which has also been tested with this config change now). So this boils down to more of a "documentation" kind of thing now. I consider this resolved now so long as y'all do too! |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2024-05-30 18:11 | Daniel Henninger | New Issue | |
2024-05-30 18:58 | Louis Abel | Assigned To | => Louis Abel |
2024-05-30 18:58 | Louis Abel | Status | new => needinfo |
2024-05-30 18:58 | Louis Abel | Note Added: 0007261 | |
2024-05-30 19:04 | Daniel Henninger | Note Added: 0007262 | |
2024-05-30 19:33 | Daniel Henninger | Note Added: 0007263 | |
2024-06-03 15:29 | Daniel Henninger | Note Added: 0007328 | |
2024-06-19 14:37 | Daniel Henninger | Note Added: 0007568 |