Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1897367
Summary: | edk2-ovmf 20200801stable results in non-functional emulated TPM in Windows guest | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrew M. <andrew> | ||||
Component: | edk2 | Assignee: | Paolo Bonzini <pbonzini> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 33 | CC: | berrange, crobinso, kraxel, lersek, marcandre.lureau, pbonzini, pbrobinson, philmd, virt-maint | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | edk2-20200801stable-2.fc33 edk2-20200801stable-3.fc33 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-12-12 01:04:40 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1269538 | ||||||
Attachments: |
|
Description
Andrew M.
2020-11-12 21:32:57 UTC
Laszlo have you heard of any edk2 regression with TPM emulation? (CC'ing Marc-André.) (In reply to Cole Robinson from comment #1) > Laszlo have you heard of any edk2 regression with TPM emulation? No, I'm not aware -- on the other hand, I certainly don't *use* TPM in any of my VMs. Andrew: would you be willing to bisect the issue perhaps? From your bug report, the problem looks bisectable. Thanks! Laszlo Yes I will try to complete a bisect this week; I agree it seems it would be helpful. It may take a while to get through, though, as there are many patch changes. Even just on the first bisect step I’m running into several build issues. Hopefully it’s not too bad, though. Created attachment 1732721 [details]
fix-tpm-enable.patch
Bisect showed 07952a962a40efe65729c3ccb9b8934571cec1af as the first bad commit. Did not revert cleanly, but didn’t matter because upon reviewing the commit the problem became apparent: compilation flag was renamed upstream, so this is a packaging issue. Patch attached, which I’ve tested and passes my test scenario.
As an aside: one aspect of this package that slowed things down somewhat when moving around a lot was the `openssl-patch-to-tarball.sh`. It’s not clear to me why this is done out-of-band from the package building itself, I did the following to simply building. Perhaps it’s worth including (would need updating of the script as well). diff --git a/edk2.spec b/edk2.spec --- a/sources/edk2/edk2.spec +++ b/sources/edk2/edk2.spec @@ -121,6 +121,7 @@ BuildRequires: qemu-img BuildRequires: genisoimage BuildRequires: bc BuildRequires: sed +BuildRequires: perl # These are for QOSB BuildRequires: python3-requests @@ -239,6 +240,7 @@ rm -rf ShellBinPkg cp -a -- %{SOURCE2} . # extract openssl into place tar -xf %{SOURCE1} --strip-components=1 --directory CryptoPkg/Library/OpensslLib/openssl +(cd CryptoPkg/Library/OpensslLib && perl process_files.pl) # extract softfloat into place tar -xf %{SOURCE4} --strip-components=1 --directory ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3/ (In reply to Andrew M. from comment #5) > Created attachment 1732721 [details] > fix-tpm-enable.patch > > Bisect showed 07952a962a40efe65729c3ccb9b8934571cec1af as the first > bad commit. Did not revert cleanly, but didn't matter because upon > reviewing the commit the problem became apparent: compilation flag was > renamed upstream, so this is a packaging issue. Patch attached, which > I've tested and passes my test scenario. Thanks for the bisection and the patch! I feel bad about not notifying Cole about this upstream change. I updated the edk2 binaries / build scripts bundled with upstream QEMU recently, and there the same flag refresh was necessary. (I didn't find it by testing; I found it by reviewing the upstream edk2 commit range that would be incorporated into the QEMU update.) See QEMU commits 504fffb9e526 ("roms/Makefile.edk2: prepare for replacing TPM2*_ENABLE macros", 2020-09-13) and e105de7579e3 ("roms/Makefile.edk2: complete replacing TPM2*_ENABLE macros", 2020-09-13). It's unfortunate I'm no longer able to "broadcast" such upstream edk2 changes to Fedora, ahead of time (and probably to a few other places that should learn about these tweaks in time). I'll attempt to file a Fedora RHBZ in advance next time. My bad. No worries Laszlo. Andrew nice work and thanks for tracking this down! I'll do a build today FEDORA-2020-ccd53da415 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ccd53da415 Reviewing the commit (https://src.fedoraproject.org/rpms/edk2/c/ce201154d66a9c56841767843d3f35ef7db058ec), it appears that only my (somewhat unrelated) suggestion about the RPM build process was committed, but not the patch to change the TPM_ENABLE compilation flag. Apologies if it was confusing that I included the former in a comment but the latter in an attachment. FEDORA-2020-ccd53da415 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ccd53da415` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ccd53da415 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-ccd53da415 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. As noted in my previous comment above this is *not* resolved as the resolving patch was not applied. (Not sure what state to move to, so just going back to “new”) Sorry for screwing it up, I'll do another build today. FEDORA-2020-78a2ed6df9 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-78a2ed6df9 FEDORA-2020-78a2ed6df9 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |