This Week in Spectrum, 2025-W37

This Week in Spectrum, 2025-W37

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 7470 bytes --]

Decided I'd rather get this out late than miss another week.
There was no This Week in Spectrum for 2025-W36, because I was too tired
after KVM Forum and NixCon to get it out on time, and in the last week I
was in the hospital for several days for various tests, including when
I'd usually send this out.

Anyway, with two and a bit weeks to cover, this is going to be a long
one.


KVM Forum
---------

Was nice to put faces on names from mailing lists — will make it easier
to approach people online to discuss new KVM things, I think.  The most
interesting talk for me was "IOMMU in rust-vmm, and new FUSE+VDUSE use
cases"[1], in which I learned:

 • virtiofsd is going to get support for additional backends, e.g. NFS
   and cloud storage.
 • A vhost-user↔VDUSE bridge is in development, which will allow
   a vhost-user device to be used by the kernel running that device.
   This raises the possibility of moving device implementations out of
   the host kernel.
 • virtio-vhost-user didn't end up getting through standardization and
   implementation not for any fundamental reason, but just because
   nobody was sufficiently motivated to make it happen.  This also came
   up again just yesterday on the virtualization list[2].  It would be
   nice to see some momentum again towards moving device implementations
   into VMs.

[1]: https://lore.kernel.org/virtualization/CAJSP0QWV+=+v9Z0wU9qJcdToDKBnWiGKzOVvAsdyTOtES=oFsw@mail.gmail.com/
[2]: https://www.youtube.com/watch?v=qsFc234tzz4&pp=ygUOaW9tbXUgcnVzdC12bW0%3D


NixCon
------

KVM Forum and NixCon partially overlapped, so I only managed to make the
second half of the latter.  I didn't see any talks, but had some good
conversations, mostly in the areas of documentation (which I hope we'll
get a lot of work done on next year) and funding / business model stuff,
which will be very important to get right to keep the project going
after NGI ends.  Speaking of which:


NGI Zero Commons Business Circle
--------------------------------

As recipients of an NGI Zero grant, we have access to various support
services[3].  One of these is called "Business Circle", and provides
business consulting and mentorship.  I had an initial call with them
after I got home after NixCon.  Not much to report yet, but it does
sound like we'll have lots of support available with legal etc. stuff if
we need it to take the project forward.

[3]: https://nlnet.nl/NGI0/services/


Cloud Hypervisor
----------------

Demi and I are currently working on sandboxing services on the Spectrum
host — best effort defense in depth, since these services are part of
our TCB anyway.  One easy win there, I thought, would have been enabling
Cloud Hypervisor's support for locking itself down with landlock,
preventing it from accessing any non-allowlisted files.  This should
have been just a case of turning it on, and passing it a couple of extra
paths to allow access to so VMs were allowed to have new devices passed
through to them after creation, but I ended up finding quite a few bugs
in the implementation in Cloud Hypervisor which had to be fixed first.
The default rules were overly strict, resulting in VSOCK being
non-functional if enabled[4], and in it failing to start at all on many
aarch64 machines[5], and I also found that if landlock was requested,
but the kernel didn't support it, Cloud Hypervisor would just start
anyway, without landlock[6].  I've fixed all of these upstream now, and
conveniently, a new Cloud Hypervisor release was scheduled for a couple
of days afterwards, so these changes have already made their way into
Spectrum.  I haven't committed the Spectrum-side landlock stuff though,
as I want to test it a bit more first.

[4]: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/7334
[5]: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/7331
[6]: https://github.com/cloud-hypervisor/cloud-hypervisor/pull/7335


rust-vmm
--------

The next step towards sound support in Spectrum is running
vhost-device-sound on the host, but we can't currently do this robustly
(and without polling), because vhost-device-sound doesn't support any
form of socket activation or readiness notification.  I've been working
on adding support for the former, but it turned out not to be possible
to implement with the current interface of the vhost-user-backend crate.
In fact, I discovered, all the vhost-device devices create a new socket
each time they're ready to accept a connection, meaning that, after the
end of a connection, there's a window where a new connection can't be
accepted.  The right thing to do here is to reuse a socket between
requests, and making that change will conveniently also make it
straightforward to optionally pass in a socket provided by the service
manager rather than creating it in the vhost-device program, so I
changed the vhost-user-backend API[7], and am now waiting for a release,
at which point I'll submit my changes to vhost-device-sound to update
vhost-user-backend, fix the race between connections, and add support
for using an externally provided socket.

[7]: https://github.com/rust-vmm/vhost/pull/321


udev
----

Demi has been working on switching the host system from mdevd to
systemd-udevd, with the motivation being that systemd-udevd comes with a
big database of device quirks, which are likely to be beneficial to us
in our aim of broad hardware support.  This was originally done as part
of her experiment with booting Spectrum with systemd[8], but has now
been extracted into a standalone series[9], which is currently awaiting
review.  One of the complications of this, as I understand it, is that
unlike every other service we run, we're not confident it's okay to
start services that depend on udev as soon as the udev control socket is
created, so we needed an adapter from systemd's readiness notification
protocol to s6's.

[8]: https://spectrum-os.org/lists/archives/spectrum-devel/20250904-systemd-v1-0-2a63b790a913@gmail.com/
[9]: https://spectrum-os.org/lists/archives/spectrum-devel/20250913-udev-v1-0-eade4ab8f2b4@gmail.com/


xdp-forwarder
-------------

Yureka submitted a new version of her program for forwarding packets
between two network interfaces[10], which will be part of our new
networking stack.  The idea here is that we can get the program reviewed
and committed without having to wait for everything to be ready to
switch to it.  There were some more review comments from Demi and me,
but nothing major, so I expect we'll see this part of the networking
work finished soon.

[10]: https://spectrum-os.org/lists/archives/spectrum-devel/20250906141228.2357630-1-yureka@cyberchaos.dev/


Ergonomics and other small improvements
---------------------------------------

Demi has been submitting a lot of small fixes and improvements for the
Spectrum development experience.  Between conferences and the hospital I
haven't had a chance to look at many of these yet, but I did apply a few
of the most straightforward ones already.


Of course, there have also been all the usual recurring things like
server updates, Nixpkgs reviews and contributions, and so on, but this
is getting far too long already, so I'm going to leave it here.
Hopefully at the end of this week I'll be able to get back to regular
updates of reasonable length…

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]