I did a dnf update today, and suddenly I can create a VM with a swtpm with
enforcing turned on!
I no longer get the swtpm_setup error at all.
I did see:
root@fedora:~# ausearch -c ‘swtpm_localca’
I’m thinking this is a “me” problem with my setup and not something with the overall fedora 40 considering I appear to be the only one who can replicate the issue. I’m able to create a VM with the qcow2 file using a system VM, however it does not recognize a bootable drive, despite the same image working in session VM I’m thinking I should just proceed down the path of figuring out what I can do to fix that instead of trying to get my existing session VMs working again.
Yes to all your questions, and I replied on the issue here:
2278905 – Creating AND using VMs not working IF swtpm is used AND IF SELinux is enabled; virt-manager is used; creating and using swtpm VMs causes different AVC denial logs
1 Like
@safforddr It would be nice if you give us the output of sudo cat /var/log/dnf.lo* | grep 2024-05-03 | grep fc40 | grep grade to get indication what solved the issue. I am not sure about your time zone, so please change (in the command) the date 2024-05-03 to 2024-05-04 if the update that solved the issue was contained on 4th.
On one hand, that helps to fix the issues of the others. On the other hand, this helps to ensure it does not occur again with some later update or so.
Btw, you did not remove swtpm.x86_64 0.8.1-7.fc40 after you tested it, did you?
I think you never experienced this very denial, so I am not wondering that it does not cause an output
Maybe, maybe not. At this time, I think you have installed 0.8.1-7.fc40 at the very morning along with your other updates through discovery, since discovery seems to not cause dnf logs. This also explains that “dnf reinstall” lead to the reinstalling of 0.8.1-7.fc40: when I tested it, dnf reinstall radically reinstalled the very version that used to be installed, even if updates are available.
I assume you saw that you are not the only one who’s session mode has broken since that day.
quote=“Chris, post:65, topic:114254, username:py0xc3”]
I assume you saw that you are not the only one who’s session mode has broken since that day.
[/quote]
Actually I logged off last night before Vlad reported that their session mode was also broken and Stefan had just responded to the bug saying he couldn’t replicate the behavior for either session or system modes. Also, my understanding of the dnf upgrade/reinstall was not there, so I kind of thought I was alone at the time. Your dnf reinstall behavior explanation helped a lot.
That information about “dnf reinstall” behavior makes sense and so the idea now is that I actually did have the stable version swtpm update installed before my issues started and doing the reinstall afterwards only demonstrated that it was already installed at that time, so it would make sense the update potentially broke my ability to start up existing/new VMs in session mode.
Some progress on my front: this morning I was finally able to get both of my existing VM disk images stood up system mode. Embarrassingly, I thought they were win11, but they’re actually win10 images, so I just had to choose the right OS when defining them…
This means, I’ve caught up to Vlad and have a functioning system mode VM (defined new since f40) and my session mode VM (defined pre-f40) are non-functional, at the moment.
That said, I’ll continue to monitor the bug on bugzilla and issue here and retest session mode and provide any additional logs or requested sample data as things progress to validate that when the root cause is identified and a fix is pushed, that it covers/resolves my case.
On May 2:
2024-05-02T20:50:44-0400 DEBUG Upgraded: swtpm-0.8.1-7.fc40.x86_64
2024-05-02T20:50:44-0400 DEBUG Upgraded: swtpm-devel-0.8.1-7.fc40.x86_64
2024-05-02T20:50:44-0400 DEBUG Upgraded: swtpm-libs-0.8.1-7.fc40.x86_64
2024-05-02T20:50:44-0400 DEBUG Upgraded: swtpm-tools-0.8.1-7.fc40.x86_64
This did not fix the problem.
On May 3:
2024-05-03T18:15:56-0400 DEBUG Upgraded: swtpm-selinux-0.8.1-7.fc40.noarch
which DID fix the problem.
The swtpm_localca error never appeared before, because the swtpm_setup error
terminated the VM creation attempt before getting to that step.
The swtpm_localca error was not fatal, and the VM creation succeeded,
although probably with a swtpm that had no endorsement certificate.
When I used ausearch and semodule to fix the swtpm_localca AVC denial,
the created VM definitely had a proper swtpm certificate.
dave
Okay, that explains it. The SELinux policy, which is the actual update, was not installed on your system with the original update but later on 3rd May. I assume you used some update command that only updated packages of your x86_64 architecture, while the SELinux policies are noarch (the package is equal for all architectures)
So effectively, you have not tested the fixing update before 3rd of May. This means the recent update fixed your issue.
So your issue seems solved, and since the update caused some new issues, we now need to find out how to solve the new issue without re-creating the old. But that shall remain in the bug report, along with the issue of bug2k24.
Formally, we should mark this topic as solved, but I would like to leave it open for now to avoid confusion since this has become interrelated with bugzilla and two maintainers who are involved in this.
@safforddr we seem to have an update candidate that solves the new issue - could you test that the old one also remains solved? Just to ensure the old one does not re-occur with the next update (there are still open questions about the overall issue, which is why I would like to have a test about that from an affected user before pushing this to stable updates) …
→ test here dnf update https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/8.fc40/noarch/swtpm-selinux-0.8.1-8.fc40.noarch.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/8.fc40/x86_64/swtpm-0.8.1-8.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/8.fc40/x86_64/swtpm-libs-0.8.1-8.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/8.fc40/x86_64/swtpm-tools-0.8.1-8.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/swtpm/0.8.1/8.fc40/x86_64/swtpm-tools-pkcs11-0.8.1-8.fc40.x86_64.rpm
It is possible that dnf will not update all packages that are contained in this command, but that is fine. dnf can identify itself which it needs.
After updating to swtpm-0.8.1.7.
Windows 11 VM on gnome boxes failed to start, observed the following avc denials:
May 04 09:16:35 grumpey0 audit[3411]: AVC avc: denied { create } for pid=3411 comm="swtpm" name="1-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c31,c772 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0
May 04 09:16:35 grumpey0 audit[3420]: AVC avc: denied { create } for pid=3420 comm="swtpm" name="2-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c256,c313 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0
May 04 09:16:51 grumpey0 audit[3522]: AVC avc: denied { create } for pid=3522 comm="swtpm" name="3-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c477,c1002 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0
May 04 09:18:14 grumpey0 audit[3679]: AVC avc: denied { create } for pid=3679 comm="swtpm" name="4-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c521,c560 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0
May 04 09:20:55 grumpey0 audit[4478]: AVC avc: denied { create } for pid=4478 comm="swtpm" name="5-win11-2-swtpm.sock" scontext=unconfined_u:unconfined_r:svirt_t:s0:c423,c863 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=0
After installing swtpm-0.8.1.8, I was able to start the VM and I am not currently observing any denials.
Thanks
3 Likes
I can also confirm that I can start my VMs without denials in session mode on the new release candidate swtpm-0.8.1.8! Great!!
@grumpey @bug2k24 @targetedpanda if you want, you can already add +1 to “karma” in the bodhi page. Formally, it does not solve BZ#2278905 but only the issue caused by swtpm-0.8.1-7 (which ended up in the BZ#2278905 bug ticket). However, important is to add the karma +1, leave the BZ# field neutral and then you could add a brief comment what exactly the very impact of this 0.8.1-8 update is for you (also, if applicable, the difference to 0.8.1-7) to keep comprehensibly documented the development of the issue(s).
If we get three people to add karma, the update can be pushed to stable by the maintainer and does not need to wait for 14 days. This might have an impact for other users with that issue.
Bodhi page: FEDORA-2024-51614125b7 — bugfix update for swtpm — Fedora Updates System
Hopefully, the next update comes soon to finally also get solved the system mode issue of @bug2k24 
Big thanks to Stefan for getting these updates provided so quickly!
2 Likes
Upgrading:
swtpm x86_64 0.8.1-8.fc40 @commandline 29 k
swtpm-libs x86_64 0.8.1-8.fc40 @commandline 50 k
swtpm-selinux noarch 0.8.1-8.fc40 @commandline 22 k
swtpm-tools x86_64 0.8.1-8.fc40 @commandline 111 k
Removing dependent packages:
swtpm-devel x86_64 0.8.1-7.fc40 @updates-testing 15 k
I had to remove the swtpm-devel from testing, but this set of packages
WORKS, with no AVC issues for swtpm, swtpm-setup, or swtpm-localca,
when authoring or running a new VM from virt-manager.
THANKS!
Thanks for the confirmation If you want, you can also add +1 Karma in bodhi ( FEDORA-2024-51614125b7 — bugfix update for swtpm — Fedora Updates System )
The above update to 0.8.1-8.fc40 has been obsoleted by swtpm-0.8.1-9.fc40, which aims to finally also solve the issue of bug2k24. No need to further put karma to the old one (it seems sufficiently confirmed that the session mode issue has been solved). I guess it makes sense to wait to see if that new one solves the issues of bug2k24 before putting more karma into it.
But I might ask later to get some karma in order to get the final update pushed asap to stable to finally get all issues solved on all affected systems.
I’m not sure I’ll be around later, so I put karma on 1.9 after installing the 1.9 version and validating it didn’t break my setup that had been fixed on 1.8 and indicated as such. Hopefully bug2k24 will be able to confirm and add their karma.
Thanks!
Any confirmation helps to ensure the next push to stable finally fixes all open issues, but this is not a question of hours. My goal is just to not wait 14 days, and at the best, also get some explicit verification that all issues of all builds have been solved before pushing it to stable. So don’t worry about doing it today or tomorrow. Everything less than 14 days has an noteworthy impact 
I suggest anyway to wait that the open issues have been solved before testing any new build: it is possible that further builds get obsoleted. I think Stefan does not want to push something into stable until all open issues have been solved, to ensure that we fully understand all issues before the next push (to avoid something like the session issue of 0.8.1-7 and such).
1 Like
The latest version 0.8.1-9.fc40 fixes the issue for me. I am now able to create and start VMs using tpm in both system and session mode.
1 Like
It seems that 0.8.1-9 finally solves the last remaining bug. Everyone is encouraged to verify that none of the recently occurred issues occur with the update ( you can install it with sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-4e9a0ffab8 ) and add +1 Karma (green thumbs up) in Bodhi to get the update pushed to the stable updates as soon as possible (and without further issues): FEDORA-2024-4e9a0ffab8 — bugfix update for swtpm — Fedora Updates System
Let us know if any of the bugs still appear here or in bugzilla BZ#2278905.
Once the update is pushed to stable, and if nothing further comes up, I will mark that a simple update with refresh shall fix any potential cause of this occurrence.
2 Likes
was fighting this issue today like full day even i got edited tpm to gnome boxes vm file it still fails and just 30 minutes ago i got updates where it just updated everyhting and even windows 11 can be installed on gnome boxes
1 Like
0.8.1-9 solves all issues we have documented in the recent days around swtpm and SELinux. The update is now available in the stable updates.
Every issue that was tackled in this topic (unfortunately more than 1 in the end) can be solved with:
sudo dnf update --refresh
Please ensure to include the --refresh to ensure that metadata is refreshed before updating because the update is fairly new
Don’t wonder: 0.8.1-10 is also already on its way, but this one aims only to solve finally the last remaining avcdenials output by Vladislav’s (and likely other) machine, but these do not cause issues / impacts. So for usersm 0.8.1-10 should have no obvious impact except some changes in the logs in the background
( users of Silverblue / Kinoite should use rpm-ostree to update )
4 Likes