Re: [PATCH 0/9] qemu: support passt as the backend for vhost-user network interfaces
On Fri, 14 Feb 2025 03:17:06 -0800
Andrea Bolognani <abologna(a)redhat.com> wrote:
On Thu, Feb 13, 2025 at 01:19:44PM -0500, Laine Stump wrote:
> passt (https://passt.top) provides a method of connecting QEMU virtual
> machines to the external network without requiring special privileges
> or capabilities of any participating processes - even libvirt itself
> can run unprivileged and create an instance of passt (which *always*
> runs unprivileged) that is then connected to the qemu process (and
> thus the virtual machine) with a unix socket.
>
[...]
>
> So far this has been tested both unprivileged and privileged on Fedora
> 40 (with latest passt packet) and selinux enabled (there are a couple
> of selinux policy tweaks that still need to be pushed to
> passt-selinux) as well as unprivileged on debian (I *think* with
> AppArmor enabled) and everything seems to work.
Unfortunately unprivileged VMs don't actually benefit from AppArmor
isolation. See [1] for a recent discussion about this.
I quickly reported to Laine about a test I made with the workaround I
proposed there. That's what it means by "working with AppArmor". It's
simply passt with:
https://archives.passt.top/passt-dev/20250205163101.3793658-1-sbrivio@red...
(merged but not released yet).
> Also, you will need the latest (20250121) passt package.
I truly appreciate the amount of information you've included in the
cover letter, especially the details about required passt version and
missing SELinux bits. That made it much easier for me to jump in with
some confidence.
Speaking of SELinux, with the current policy on Fedora 41 I get a
couple of AVC denials related to accessing the shared memory file.
I understand that's expected, based on the above, but it's still
quite surprising to me that the VM would start at all in this case.
Just for the record, it's with this:
https://archives.passt.top/passt-dev/20250213221642.4085986-1-sbrivio@red...
as you found out meanwhile. Of course, it's temporary (and not even
released yet).
Just like the scenario that I've mentioned in my reply to 9/9,
the
network interface quietly being broken doesn't make for a great user
experience. I believe this specific failure scenario, unlike the
other one, is pre-existing and not easy to deal with purely through
XML validation, but I really think that we should spend some effort
(as a follow-up) on making sure that, if passt can't set up the
network interface successfully, we report a useful error to the user
instead of just leaving things broken with no clear indication that
they are.
I guess that's a valid follow-up improvement regardless of the
workaround I'm about to release in passt's policy.
--
Stefano