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 - edk2-ovmf 20200801stable results in non-functional emulated TPM in Windows guest
Summary: edk2-ovmf 20200801stable results in non-functional emulated TPM in Windows guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: edk2
Version: 33
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paolo Bonzini
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2020-11-12 21:32 UTC by Andrew M.
Modified: 2020-12-12 01:04 UTC (History)
9 users (show)

Fixed In Version: edk2-20200801stable-2.fc33 edk2-20200801stable-3.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-12 01:04:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
fix-tpm-enable.patch (deleted)
2020-11-23 21:57 UTC, Andrew M.
no flags Details | Diff

Description Andrew M. 2020-11-12 21:32:57 UTC
Description of problem:

Emulated TPM is no longer functional in Windows 10 guest after upgrade to edk2-ovmf-20200801stable


Version-Release number of selected component (if applicable):

edk2-ovmf-20200801stable-1.fc33.noarch


How reproducible:

Always


Steps to Reproduce:
1. Be running edk2-ovmf-20200201stable
1. Create Windows 10 guest VM in libvirt using q35 (was on pc-q35-4.1, also an issue on 5.1)
2. Add a TPM, v2.0, emulated, CRB
3. Boot the VM
4. Open Windows device manager, witness TPM device is functional
5. Shutdown VM
6. Upgrade to 20200801stable
7. Start VM, open Windows device manager


Actual results:

TPM device is listed as unable to start (Code 10)


Expected results:

TPM device is listed as functional


Additional info:

Since this on an existing VM, I also tried wiping the swtpm state in /var/lib/libvirt/swtpm as well as re-adding the TPM device in virt-manager, all to no avail.

edk2-ovmf is the only difference, downgrading it results in a functional TPM.

I have not tried with other guest OS.

This was also an issue on F32, but only getting around to submitting a bug now.

Comment 1 Cole Robinson 2020-11-12 22:19:40 UTC
Laszlo have you heard of any edk2 regression with TPM emulation?

Comment 2 Laszlo Ersek 2020-11-13 19:57:38 UTC
(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

Comment 4 Andrew M. 2020-11-22 04:42:39 UTC
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.

Comment 5 Andrew M. 2020-11-23 21:57:13 UTC
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.

Comment 6 Andrew M. 2020-11-23 22:11:44 UTC
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/

Comment 7 Laszlo Ersek 2020-11-23 23:53:12 UTC
(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.

Comment 8 Cole Robinson 2020-11-24 13:29:46 UTC
No worries Laszlo. Andrew nice work and thanks for tracking this down! I'll do a build today

Comment 9 Fedora Update System 2020-11-24 17:48:03 UTC
FEDORA-2020-ccd53da415 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ccd53da415

Comment 10 Andrew M. 2020-11-24 21:09:57 UTC
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.

Comment 11 Fedora Update System 2020-11-25 02:12:11 UTC
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.

Comment 12 Fedora Update System 2020-12-01 01:27:50 UTC
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.

Comment 13 Andrew M. 2020-12-01 22:45:17 UTC
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”)

Comment 14 Cole Robinson 2020-12-03 13:38:56 UTC
Sorry for screwing it up, I'll do another build today.

Comment 15 Fedora Update System 2020-12-07 14:57:47 UTC
FEDORA-2020-78a2ed6df9 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-78a2ed6df9

Comment 16 Fedora Update System 2020-12-12 01:04:40 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.