qemu-system-x86_64: -device tpm-tis,tpmdev=tpm-tpm0,id=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm-tpm0'

I've tried many different workarounds by editing the /usr/bin/kvm wrapper or even adding custom KVM arguments to /etc/libvirt/qemu/Win10.xml, but nothing worked for me. The root cause could be in qemu patches. I've found a thread mentioning the above is a regression.

Possibly related ... https://<email address hidden><email address hidden>/

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Hello Alex. It's ok, I was unsure with the security classification. The attackers could cross the boundaries as a direct result of the user's inability to encrypt disc drives using BitLocker, so ... it isn't a "hidden" security problem, but it still affects the security at certain level.
Yesterday I tried to rebuild qemu 5 from Ubuntu 20.10 against 20.04 and the issue is present even in the newer version.

Status changed to 'Confirmed' because the bug affects multiple users.

At least for the mentioned issue (Thanks Jaromir) d10e05f15d was in qemu v3.1.0

The fixup is in
https://git.qemu.org/?p=qemu.git;a=commit;h=88f830745721ba8c9e9d2831c01045a6f130c1a6
which is in qemu >=5.1

On an otherwise identical system I can reproduce the issue:

1:4.2-3ubuntu6.11

$ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -chardev null,id=tpm0 -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: tpm chardev 'chrtpm' not found.
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: Could not cleanly shutdown the TPM: No such file or directory
QEMU 4.2.1 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: -device tpm-tis,tpmdev=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm0'

1:5.0-5ubuntu9.2~backport20.04-202011301725~ubuntu20.04.1

root@f:~# qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -chardev null,id=tpm0 -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: tpm chardev 'chrtpm' not found.
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: Could not cleanly shutdown the TPM: No such file or directory
QEMU 5.0.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: -device tpm-tis,tpmdev=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm0'

1:5.1+dfsg-4ubuntu1~ppa4

$ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -chardev null,id=tpm0 -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: tpm chardev 'chrtpm' not found

1:5.2+dfsg-3ubuntu1

root@h:~# qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -chardev null,id=tpm0 -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: tpm chardev 'chrtpm' not found

So it seems to confirm that starting with 5.1 and later that particular issue is gone.
My environment isn't necesarily useful for TPM. That other remaining issue around the chardev that I have might not apply to you.

Could you give the qemu 5.2 from Ubuntu 21.04 Hirsute a try please in your environment.
If it would work we can try to backport the changes to at least Focal+Groovy I'd say.

And thanks Alex for retargetting it against qemu, I haven't seen it before.

The above is for emulator which IMHO meant for use with swtpm so I should use it I guess ...

$ swtpm socket --tpmstate dir=/tmp/mytpm1 --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock --log level=20
$ qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0

^^ this seems to work and gets qemu started even with 1:4.2-3ubuntu6.11 +
1:5.0-5ubuntu9.2~backport20.04-202011301725~ubuntu20.04.1

So all of this might also somewhat depends on the emulator setup as well.
What did you use for that.
Did you use swtpm, how did you (or your surrounding tooling) start it?

But to counter the "it is just swtpm details" argument a bit:
A passthrough case (without swtpm emulator) seems affected by the same issue that originally was reported:

1:4.2-3ubuntu6.1

$ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -tpmdev passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev passthrough,id=tpm0,path=/dev/tpm0: tpm_passthrough: Could not guess TPM cancel path
QEMU 5.0.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: -device tpm-tis,tpmdev=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm0'

A friend of mine tried the passthrough case on Hirsute (qemu 5.2) and he got past this error as well. It is still failing at "Could not guess TPM cancel path". But since none of us has had a working TPM env before we could not call that a regression. At least the reported issue seems to be solved with this.

So we are back @Jaromir - could you try the qemu 5.2 in Ubuntu 21.04 if that would work for you?

Hi,
I was reconsidering the state of the bug - in triaging for the issue "Property 'tpm-tis.tpmdev' can't find value 'tpm-tpm0'" that was reported I think - until further feedback - we'll have to consider (see posts above) as fixed in Hirsute.

Further actions (e.g. considering backports for focal) will depend on confirming what I've found and some help to test this.

Hi Christian,

I can help confirming/testing this. I currently experience this issue on 18.04. What do I need to do? Testing TPM from a bootable stick with 21.04 would be enough?

Hi André,
this is about qemu's ability to either emulate and/or pass-through a TPM.
A bootable stick of 21.04 would be fine, then please run:
a) whatever you tried to do on 18.04 that failed you
b) the passthrough case I mentioned above
  $ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -tpmdev passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0

With qemu 5.2 the initially reported issue of "Property 'tpm-tis.tpmdev' can't find value 'tpm-tpm0'" should be gone. If you could confirm this, that would help.

Then if it is indeed gone continue to tweak your command to achieve what you actually wanted to achieve (to check if there are other issues left).

Hey,

I was able to reboot my machine and run some tests tonight. From my side, I am following the template in the following link: https://github.com/ohthehugemanatee/win10vm. Same company, same limitations - I am just skipping the networking part for now.

First, your command looks good:

ubuntu@ubuntu:~$ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -tpmdev passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0
QEMU 5.2.0 monitor - type 'help' for more information
(qemu)

For my VM, I do get past tpm (yey!), but I am stuck on this other issue. I am attaching the results of the commands bellow with LIBVIRT_DEBUG=1. Sorry, I am really just guessing that this is the debugging info needed.

ubuntu@ubuntu:~$ virsh start win10.2
error: Failed to start domain win10.2
error: Could not open TPM device /dev/tpm0: Permission denied

ubuntu@ubuntu:~$ sudo virsh start win10.2
error: failed to get domain 'win10.2'

Hi André,
thanks for confirming that the original issue is indeed fixed with that.
Let us keep this bug here for considerations / discussions on backporting that change.

For this bug I've created preliminary fixes for Focal and Groovy in this PPA.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4410
If you could let me know how those builds work for you in those releases that would be great.

---

I've split your related but new issue into bug https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1913552
Please chime in and continue there for this new issue.

Hi Christian,

Thanks for the new build. It looks promising. And sorry for saying I was on 18.04. You were right to assume Focal instead. :-)

This is on Focal with your PPA:

 ~$ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -tpmdev passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0
QEMU 4.2.1 monitor - type 'help' for more information
(qemu)

I will now switch to Groovy and test with qemu 1.5.0.

Hi,

Now this is from Groovy (which is the best mascot ever BTW) with the PPA:

ubuntu@ubuntu:~$ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -tpmdev passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0
QEMU 5.0.0 monitor - type 'help' for more information
(qemu)

Ok, so it seems we can fix the issue we have "here" with the changes I have prepared.
There are a few more changes to release an SRU and I'll want to bundle them, so there might be a bit of delay.

Also there will be another round of security updates before these, so I beg your pardon for some delay.

Uploaded to Focal/Groovy unapproved fro consideration by the SRU Team.

This is about to be accepted into -proposed following the SRU process.
That is good and we want to do it that way, especially for joint test and verification.
But we have a follow on upload that will go to -security afterwards, so we will "release" only one to save users one extra upgrade.
Therefore I'm adding a block-proposed tag to this bug.

Hello Jaromír, or anyone else affected,

Accepted qemu into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:5.0-5ubuntu9.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Jaromír, or anyone else affected,

Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.13 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.13) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

edk2/0~20191122.bd85bf54-2ubuntu3.1 (amd64)
open-iscsi/2.0.874-7.1ubuntu6.1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

I've started to resolve these test fails.

@Andre - do you have a chance to verify these on Focal and Groovy to pass that former blocking issue or should I set something up?

FYI - autopkgtest issues in Focal resolved

I've checked that the swtpm style is still working:

The following does not expose new-issues due to the upgrade:
$ qemu-system-x86_64 -display none -accel kvm -m 1024 -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0

But I have OTOH failed to verify the positive effect.
The command working in later releases like:
 $ lxc config device add f tpm tpm path=/dev/tpm0
 # Then in the container
 $ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio -tpmdev passthrough,id=tpm0,path=/dev/tpm0 -device tpm-tis,tpmdev=tpm0

Keeps failing for me on the backports for Focal/Groovy.
I have double checked if the build really contains the changes we have tested successfully from the PPA and it seems it does.

But then my setup was never super-great emulating much of what should be real.

@Andre - If you could give the builds in -proposed a try just as you did in comment #14 / #15 that would be great and very helpful!

I was giving the debugging of this some more time.
I was finding that some newer kernels don't expose /sys/class/tpm/tpm0/device/cancel
anymore which is the reason in some places for the "Could not guess TPM cancel path".
One can trick around these cases by providing a fake cancel path tou:
  $ touch /tmp/foo-cancel
  $ ... -tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/tmp/foo-cancel

With that the use case of TPm passthrough is working even with the kernel
not exposing thise e.g.:
  $ sudo qemu-system-x86_64 -nodefaults -S -display none -monitor stdio \
   -tpmdev passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/tmp/foo-cancel \
   -device tpm-tis,tpmdev=tpm0
But it does so with 1:4.2-3ubuntu6.12 just as much as with 1:4.2-3ubuntu6.13.

But that isn't everything. I further realized that using the TPM as passthrough
will once the guest detaches set it in a disabled state. In that state it will
be rather useless until the next reboot of the host system to re-initialize it.
That further explains some of the inconsistent results.

Further we were so far relying on user-testing of our code e.g. in #14 / #15
thanks to Andre. But having him not available makes me need to verify it alone.
Since I lack his setup I need to use what I have and that alignes to what
the patch is meant to fix as described by upstream.

I was able to confirm that the formerly misleading error:
$ sudo qemu-system-x86_64 -tpmdev emulator,id=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: Failed to send CMD_SET_DATAFD: Success
qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: Could not cleanly shutdown the TPM: Success

Is now much more clear:
$ sudo qemu-system-x86_64 -tpmdev emulator,id=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: parameter 'chardev' is missing

So I was able to confirm that this indeed fixes an issue.
If it fixes the originally reported issue - I can't say as I don't have
the same setup.

I was also setting up another laptop for this to test tpm passthrough there.
I was able to verify all I've said above and didn't find a regression (e.g.
with swtpm usage that worked before an after), but I also didn't re-create the
good results of #14/#15.
Also consdiering all the limitatons I've identified that even the intended
testcase as documented above works fine - but it does so with the old and
with the new version.

Let me I'd summarize:
a) we seem to not regress TPM usage (and the reported use case works)
   Although it would not need this fix for it :-)
b) we fix a real issue (although just a misleading message)
c) the SRU combines a few fixes, the other alone would qualify for an SRU
   so releasing this is not "a useless update for just this error message"

Therefore I'd want to set this verified to release the fix.
If later on Andre or jaromir come back and confirm that while helpful it
didn't fix "their" issue we can split that into a new bug and consider potential
steps and fixes for that in this new case.

IMHO that would allow to resolve this at no cost (effort of re-spinning,
re-reviewing, re-testing the SRU). And has no drawback I could identify.

This bug was fixed in the package qemu - 1:5.0-5ubuntu9.6

---------------
qemu (1:5.0-5ubuntu9.6) groovy-security; urgency=medium

  * SECURITY REGRESSION: fix multiple regressions caused by CVE-2020-13754
    security update (LP: #1914883)
    - debian/patches/ubuntu/CVE-2020-13754-3.patch: log invalid memory
      accesses in memory.c.
    - debian/patches/ubuntu/CVE-2020-13754-4.patch: allow 16-bit writes to
      memory region in hw/riscv/sifive_test.c.
    - debian/patches/ubuntu/CVE-2020-13754-5.patch: allow 64-bit accesses
      in hw/timer/slavio_timer.c.
    - debian/patches/ubuntu/CVE-2020-13754-6.patch: allow less than 32-bit
      accesses in hw/char/bcm2835_aux.c.
    - debian/patches/ubuntu/CVE-2020-13754-7.patch: unbreak size mismatch
      memory accesses in hw/display/artist.c.

 -- Marc Deslauriers <email address hidden> Wed, 10 Feb 2021 08:10:20 -0500

This bug was fixed in the package qemu - 1:4.2-3ubuntu6.14

---------------
qemu (1:4.2-3ubuntu6.14) focal-security; urgency=medium

  * SECURITY REGRESSION: fix multiple regressions caused by CVE-2020-13754
    security update (LP: #1914883)
    - debian/patches/ubuntu/CVE-2020-13754-3.patch: log invalid memory
      accesses in memory.c.
    - debian/patches/ubuntu/CVE-2020-13754-4.patch: allow 16-bit writes to
      memory region in hw/riscv/sifive_test.c.
    - debian/patches/ubuntu/CVE-2020-13754-5.patch: allow 64-bit accesses
      in hw/timer/slavio_timer.c.
    - debian/patches/ubuntu/CVE-2020-13754-6.patch: allow less than 32-bit
      accesses in hw/char/bcm2835_aux.c.
    - debian/patches/ubuntu/CVE-2020-13754-9.patch: fix
      valid.max_access_size to access address registers in
      hw/usb/hcd-xhci.c.

 -- Marc Deslauriers <email address hidden> Wed, 10 Feb 2021 08:17:08 -0500

Hi folks, I think the new version of the qemu package in Groovy at least has regressed an important aspect for us in testing Ubuntu Core 20 VM's with swtpm. We use the swtpm-mvo snap in conjunction with qemu and OVMF to run Ubuntu Core 20 VM's, and after upgrading to qemu 1:5.0-5ubuntu9.6, I can no longer run UC20 VM's using the swtpm-mvo snap we use on the snapd team.

I see this:

```
$ kvm \
     -smp 8 \
     -m 8192 \
     -machine q35 \
     -cpu host \
     -global ICH9-LPC.disable_s3=1 \
     -netdev user,id=mynet0,hostfwd=tcp::8022-:22 \
     -device virtio-net-pci,netdev=mynet0 \
      -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
      -drive file="$SCRIPT_DIR/OVMF_VARS.ms.fd",if=pflash,format=raw,unit=1 \
     -chardev socket,id=chrtpm,path="/var/snap/swtpm-mvo/current/swtpm-sock" -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 \
     -drive file=uc20.img,if=none,format=raw,id=disk1 -device virtio-blk-pci,drive=disk1,bootindex=1 \
     -serial mon:stdio
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: Failed to send CMD_SET_DATAFD: Success
qemu-system-x86_64: -device tpm-tis,tpmdev=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm0'
$
```

whereas before this worked and we could use the TPM. You can reproduce this by installing the swtpm-mvo snap:

```
$ snap install swtpm-mvo --edge
```

and then using the ubuntu core 20 released image from cdimage: http://cdimage.ubuntu.com/ubuntu-core/20/stable/current/

Note that you have to make a copy of the OVMF_VARS.ms.fd from /usr/share/OVMF/OVMF_VARS.ms.fd (which is from the ovmf package), and then when you are able to boot a VM with the command line enable secure boot via the OVMF EFI setup. At that point with the above command line you should be able to boot UC20 with full disk encryption enabled using the swtpm.

So I tested the swtpm-mvo snap in a hirsute live image from current/ on cdimage, using kernel 5.8.0-36-generic (which is only slightly older than my current groovy kernel at 5.8.0-44-generic), and qemu 1:5.2+dfsg-3ubuntu1, and it worked for me to use the swtpm from the swtpm-mvo snap. So I think that something is related to this is fixed in hirsute which has not been fixed/backported to groovy for our use case of booting UC20 VM's.

Hi Ian,
the fix we backported to Focal/Groovy so far only was about fixing the argument validation and the related error message. So before you might have had:
 qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: Failed to send CMD_SET_DATAFD: Success
 qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: Could not cleanly shutdown the TPM: Success

Which reads a lot like success, but it was failing and had no good indication why.
While with the improved parsing and error you'd now get something like:

qemu-system-x86_64: -tpmdev emulator,id=tpm0: tpm-emulator: parameter 'chardev' is missing

Which more clearly points to the missing specification of a chardev for it.

The qemu 5.2 in Hirsute is known to have much more changes/fixes for tpm ussage, but those are a major (non SRUable) change (unless we can identify something smaller down the road) and also a bit a new feature - hence it seems reasonable that things work in Hirsute but might not in Focal/Groovy.

The above would be "ok'ish" but I'm wondering about you reporting that for your case that got "worse" with an upgrade to 1:5.0-5ubuntu9.6. It should really only have replaced one error condition/message for another and not broke it for you.

What I have regression checked for swtpm before was like
"-chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock
-tpmdev emulator,id=tpm0,chardev=chrtpm
-device tpm-tis,tpmdev=tpm0"
and that worked with/without the upgrade. Let me compare this to your usage ...

Yours is:
"-chardev socket,id=chrtpm,path="/var/snap/swtpm-mvo/current/swtpm-sock"
-tpmdev emulator,id=tpm0,chardev=chrtpm
-device tpm-tis,tpmdev=tpm0"
which is very similar except the path, ... hmm

I've:
- spawned a groovy system
- installed qemu-system-x86
  $ apt install qemu-system-x86
- and installed swtpm-mvo snap there.
  $ snap install swtpm-mvo --edge

And indeed I see the issue you mentioned:
$ qemu-system-x86_64 -display none -accel kvm -m 1024 -chardev socket,id=chrtpm,path=/var/snap/swtpm-mvo/current/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: Failed to send CMD_SET_DATAFD: Success
qemu-system-x86_64: -device tpm-tis,tpmdev=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm0'

Then I downgraded all qemu bits to 1:5.0-5ubuntu9 and (as I have expected) it failed just the same:

$ qemu-system-x86_64 -display none -accel kvm -m 1024 -chardev socket,id=chrtpm,path=/var/snap/swtpm-mvo/current/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-x86_64: -tpmdev emulator,id=tpm0,chardev=chrtpm: tpm-emulator: Failed to send CMD_SET_DATAFD: Success
qemu-system-x86_64: -device tpm-tis,tpmdev=tpm0: Property 'tpm-tis.tpmdev' can't find value 'tpm0'

Now I was switching from snap swtpm-mvo to the one I have used.

$ sudo add-apt-repository ppa:stefanberger/swtpm-focal
# modify it to fetch from focal (as we are on groovy)
$ vim /etc/apt/sources.list.d/stefanberger-ubuntu-swtpm-focal-groovy.list
$ mkdir /tmp/mytpm1
$ swtpm socket --tpmstate dir=/tmp/mytpm1 --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock --log level=20
$ qemu-system...

Hey Christian, thanks for taking a look at this, indeed this is somehow confinement related and I can make it work by removing the apparmor profile for the swtpm snap.

I guess I assumed that this bug was related to that since it had the same exact error message and I definitely remembered doing this setup before only like a month or two ago on Groovy and the swtpm-mvo snap has not been updated in ages so I assumed that updating qemu was to blame.

What I actually find now is that it seems actually to be due to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753, since what changed for me to trigger my bug around swtpm and qemu is that I started using VS Code as a snap, and so when I run my qemu commands they are effectively being run from inside a classic snap, and swtpm is a strict snap so it cannot inherit all the FD's that VS code has open. If I run from a normal terminal shell and not from within the VS Code integrated terminal the setup works the same again.

So all that is to say that indeed there is no regression here, thanks for the insight that this is confinement related, I should be able to easily work around this for my purposes.

Hi, I see this issue marked as resolved and released in qemu-kvm 1:5.0-5ubuntu9.5, and while I am on 1:5.0-5ubuntu9.8, I am still hitting this issue.
Particularly, I am using virtmanager with passthrough.
(have attempted emulated vTPM with https://launchpad.net/~smoser/+archive/ubuntu/swtpm packages, but hitting different issues)

Hi Vincent, there were various related issues and we need to be clear what is fixed and what is open.
The one we have fixed here was only a less useful error message.

To check if - whatever exact case you hit - is fixed in a newer release I recommend trying to upgrade (if you have a test system that allows that easily) or trying [1] which allows testing newer versions in the latest LTS.

And then if you've identified a version that works (or even if not) I' ask you to file a new bug (feel free to refer to this one for similarity) for a new discussion about what we could fix and how. Please be specific about the commands you use so that one can reproduce exactly the same (as I said there seem to be various tpm related rough edges left).

[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports