Comment 31 for bug 1903864

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-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

That works fine with 1:5.0-5ubuntu9 as well as 1:5.0-5ubuntu9.6.

So - at least in my repro - I fail to see the regression being added.
With snap swtpm-mvo it fails on old and new qemu versions (bad but no regression), while with the swtpm from the PPA of the Author it works fine old and new qemu versions (no regression and confirming that it works).

The issue we face with swtpm-mvo is "Failed to send CMD_SET_DATAFD: Success".
Comparing this and my swtpm call is:
mine: swtpm socket --tpmstate dir=/tmp/mytpm1 --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock --log level=20
swtpm-mvo: swtpm socket --tpmstate dir=/var/snap/swtpm-mvo/88/ --tpm2 --ctrl type=unixio,path=/var/snap/swtpm-mvo/88/swtpm-sock

Differences
a) log level (should not be important)
b) tpm type2 (worth to check)

I've tried "my" swtpm with --tpm2 as well, still working.

I've checked the usual suspects in this and found that with swtpm-mvo
[1458291.844261] audit: type=1400 audit(1615189234.949:2875): apparmor="DENIED" operation="file_receive" namespace="root//lxd-g-swtpm-old_<var-snap-lxd-common-lxd>" profile="snap.swtpm-mvo.swtpm-sock" pid=2816227 comm="swtpm" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send" addr=none peer_addr=none peer="unconfined"

That could be what breaks swtpm-mvo but works with my local swtpm install.
And indeed the following makes swtpm-mvo work:
$ sudo apparmor_parser -R /var/lib/snapd/apparmor/profiles/snap.swtpm-mvo.swtpm-sock

So IMHO it is a limitation in /var/lib/snapd/apparmor/profiles/snap.swtpm-mvo.swtpm-sock and not a regression in qemu AFAICS.
@Ian please recheck your setup in regard to what I've found and let me know - preferably (if it is a new case and not a regression here) in a new bug then.