Comment 4 for bug 1968187

After looking further into the call structure it seems that the denials are happening through the call structure of libvirt -> qemu -> qemu_tpm.c -> swtpm and swtpm_setup, where the two programs are borrowing the apparmor profile libvirt-[UUID] rather than using usr.bin.swtpm.

It seems like the most proper way to fix this would be to make sure swtpm uses its own profile by adding a Discrete Profile execute mode px line to the libvirt profile, such as some variation of:

/usr/bin/swtpm px
or
/usr/bin/swtpm px -> swtpm

This fixes swtpm's apparmor issues but causes a new error on start from virt-aa-helper, which fails to parse this and the following is shown:

Error starting domain: internal error: cannot load AppArmor profile 'libvirt-[UUID]'