TPM driver doesn't load in qemu Windows guest

[Kelvin Middleton]

When passing through a TPM device to a qemu Windows 10 guest Windows will fail to initialize the TMP driver with the reason: 'device cannot find enough free resources'. The bug was investigated and a patch provided upstream for qemu relesae 2.6 onwards. See original bugzilla thread here https://bugzilla.redhat.com/show_bug.cgi?id=1281413.

I've confirmed this bug also affects the stock qemu package (1:2.5+dfsg-5ubuntu10.4) in 16.04. To resolve I built the qemu 2.6.1 tarball and tested which solved the problem.

My understanding is that qemu 2.6 is slated for 16.10 only, can this updated code be brought into the 16.04 LTS family also?

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: qemu-system-x86 1:2.5+dfsg-5ubuntu10.4
ProcVersionSignature: Ubuntu 4.4.0-34.53-generic 4.4.15
Uname: Linux 4.4.0-34-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Aug 22 17:08:50 2016
InstallationDate: Installed on 2016-04-24 (119 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-34-generic.efi.signed root=UUID=2de8fff7-85ef-4fa4-ac98-ba5118e3d3c9 ro intel_iommu=on intremap=no_x2apic_optout
SourcePackage: qemu
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/17/2016
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P2.70
dmi.board.name: Z97 Extreme6
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP2.70:bd05/17/2016:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ97Extreme6:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
modified.conffile..etc.modprobe.d.qemu-system-x86.conf:
 options kvm_intel nested=1
mtime.conffile..etc.modprobe.d.qemu-system-x86.conf: 2016-08-19T21:18:23.866234

[Nish Aravamudan (nacc)]

Thank you for this bug report. It looks like the relevant upstream commits are:

http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2b1c2e8e5f1990f0a201a8cbf9d366fca60f4aa8
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=52e38eb0512585a5fadb431a65997b602d44874b

Thanks,
Nish

[Kelvin Middleton (kelvin-middleton)]

Hi Nish, do you know what release these are being targeted for? Is it just 16.10 including qemu 2.6 or will these be put into the 16.04 lifecycle?

Thanks,

Kelvin

[Nish Aravamudan (nacc)]

Hi Kelvin,

That will be a next step to determine, I'm just triaging our incoming bug reports right now. We will certainly do our best to fix it in 16.10, and then we will need to evaluate the SRU for 16.04. On my first read and estimation, this seems like a natural candidate, but we will need to see the regression potential and also how easy the patches will be to backport.

Thanks!
-Nish

[Kelvin Middleton (kelvin-middleton)]

Thank you for the confirmations Nish.

If it is of all useful the patched code in qemu 2.6.1 and 2.7.0-rc4 actually doesn't allow me to use Bitlocker with my TPM (my end game), basically the windows guest shows the passed through TPM as functional however windows tpm admin says it can't find a compatible tpm device. I'm uncertain if its a user config issue (don't really see how) or another related/unrelated bug. Regardless I filed this (https://bugs.launchpad.net/qemu/+bug/1615823) bug report against qemu and am pending a response on that.

[Nish Aravamudan (nacc)]

@Kelvin,

Ok, good to know -- if it turns out more backports are needed for full functionality, we might want to bundle them all at once to resolve both bugs. I'll subscribe ubuntu-server to that bug as well.

-Nish

[Christian Ehrhardt  (paelzer)]

Thanks a lot, I tagged this up as it was dormant for too long.
I hope I get to this rather soon as I wasn't aware at all so far.

In the other bug there was some mentioning of a newer windows release fixing it (if on qemu 2.6.1).
If one could check that for this bug as well but on 2.5 that would be nice.

[Christian Ehrhardt  (paelzer)]

Hmm, no response so far to my question if this was made working by the mentioned windows updates.
I can't test lacking the windows VM and a TPM setup on it.

Setting incomplete for now to reflect that we have to wait on the user to verify.

Given the time that has passed you could also go for the qemu 2.8 (zesty) or 2.10 (artful), as in comment #5 you mentioned that even on newer versions with the fixes applied your setup didn't work well.

TL;DR:
- please retest with windows updated on the qemu 2.5 that is in Xenial.
- if you can retest on the qemu in zesty / artful (or via Ubuntu Cloud Archive [1])

[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive

[Christian Ehrhardt  (paelzer)]

To make clear what I refer to - quoting from the "other" bug you opened:
"I can get the TPM device working in Windows 10 after I upgrade Windows to version 1607. My qemu is still 2.6.1 from ubuntu 16.10."

[Kelvin Middleton (kelvin-middleton)]

Hi apologies for the radio silence.

I've since upgrade my host so I'm now testing on zesty with stock qemu at v2.8...

Have just retested with my guest Win10Pro @ v1703.

So the original problem of the guest tpm driver getting a resource conflict is not longer an issue as per my post #5 here.

However the new update since testing today is that Windows does now recognise the TPM device but will not allow me to take ownership. Screenshot of the guest view of the TPM (https://s26.postimg.org/vter35eh5/Screenshot_20170907_114644.png). I can't "Prepare the TPM" which is Windows speak for taking ownership and I am unsure why.

As part of today's testing I have cleared the TPM via the UEFI, re-enabled the TPM, booted into my zesty host and run tpm_selftest as well as tpm_takeownership successfully and subsequently tpm_clear which required a reboot to complete. I then went back into the UEFI, re-enabled the TPM and then tested in the guest but was unable to take ownership. As such I believe the TPM interaction with the host is functional but still some functionality is not being passed through to the qemu guest?

[Christian Ehrhardt  (paelzer)]

Thanks for coming back to this Kelvin.

I must admit I lack the TPM setup and in depth knowlegde to confirm or deny if there is still something missing, but it sounds like it - either that or a setup issue I don't know about.

Good to hear that at least this particular bug here is fixed as assumed.
Since it is unclear how a Xenial SRU would have to be actioned I set that to "opinion".

For your remaining issue I'd ask you to open a new bug on launchpad against "qemu" not "qemu (ubuntu)".
There is too much old context in here, otherwise I'd say we just add a task for that project.
It is your choice which you prefer.

Before you do open that report (or add that task) you could also move to the current development release (Artful) which has the brand new qemu 2.10.
You'll sooner or later have to recheck with that anyway for a proper upstream report.

If you happen to open a new bug it would be very kind if you could report the bug number you get here, so I can subscribe myself.

[Kelvin Middleton (kelvin-middleton)]

Hey, I'm not really in a position to test a full dev release of ubuntu goodness but happy to build qemu 2.10 in isolation and test my guest with an standalone qemu 2.10 binary. Would that be acceptable?

[Christian Ehrhardt  (paelzer)]

On Thu, Sep 7, 2017 at 8:52 PM, Kelvin Middleton <<email address hidden>
> wrote:

> Hey, I'm not really in a position to test a full dev release of ubuntu
> goodness but happy to build qemu 2.10 in isolation and test my guest
> with an standalone qemu 2.10 binary. Would that be acceptable?
>

It would for the purpose of reporting upstream with it.
IMHO it is more complex than using Artful, but your decision.
Both will work.

[Kelvin Middleton (kelvin-middleton)]

Okay, so qemu 2.10 built and tested with the same results. Used Windows Powershell also to try and get more info...it would seem the Windows complaint of the lack of access to the TCG Event Log is causing it to stop the initialisation/preparation process (https://s26.postimg.org/klo854qyx/Screenshot_20170909_143841.png).

I'll raise a new bug ticket @qemu as you note in post #11 and come back here with the bug number.

I appreciate your persistence and assistance with this Christian, thank you.

Kelvin

[Kelvin Middleton (kelvin-middleton)]

New bug raised against qemu here https://bugs.launchpad.net/qemu/+bug/1716132

[Christian Ehrhardt  (paelzer)]

Great, I subscribed myself there and will track with you what the upstream feedback will be.