* Re: Spectrum community call!
2026-07-02 11:10 Spectrum community call! Alyssa Ross
2026-07-05 20:52 ` Alyssa Ross
@ 2026-08-05 14:54 ` Valentin Gagarin
1 sibling, 0 replies; 5+ messages in thread
From: Valentin Gagarin @ 2026-08-05 14:54 UTC (permalink / raw)
To: hi; +Cc: discuss, Valentin Gagarin
# 2026-07-12 Spectrum community call
Attendees:
- Alyssa
- Lilla
- Demi
- Valentin
- Johannes
- (3 more guests)
Notes: Valentin, edited for correctness by Alyssa
## Agenda
- Updates on what's been happening recently
- Q&A
## Updates from contributors
- Alyssa:
- Trying to get back to publishing weekly updates, but no promises
- Worked on updating Spectrum's Nixpkgs pin
- Hasn't been moved in 6 months
- This sort of delay should be exceptional, but was focused on
project management issues in the first half of the year
- In the future, updates should be regular and automatic
- Caught a crash in [Mesa] (via [cosmic-files]) that wasn't covered
by tests, submitted [first PR to fix that]
- We had been working on integrating [COSMIC] since 2023 (with
contributions to upstream and its dependencies), and now
[COSMIC on Spectrum is almost ready to go]
- Vaida has been working on UX design for Spectrum
- We had lots of conversations how applications should interact,
how security concepts should be communicated to users, etc.
- [Discussion of initial use cases] should soon make it into the
public development space
[Mesa]:
https://mesa3d.org/
[cosmic-files]:
https://github.com/pop-os/cosmic-files/
[first PR to fix that]:
https://github.com/rust-lang/rust/pull/159145
[COSMIC]:
https://github.com/pop-os/cosmic-epoch
[COSMIC on Spectrum is almost ready to go]:
https://inbox.spectrum-os.org/spectrum-devel/20260710195907.98981-1-hi@alyssa.is/
[Discussion of initial use cases]:
https://inbox.spectrum-os.org/spectrum-devel/CALi2N8TtTTyoK90DAm24jBTpJQBmNq5J8BnY935r62b-x0t+dA@mail.gmail.com/T/#u
- Johannes:
- Started working on the installer in October/November 2025, when Alyssa and
Demi were discussing the new update system
- The current installer wouldn't really work with that
- Tried options from other distros, but didn't find anything suitable Started implementing our own in Rust - Turned out there was already development at GNOME OS on [gnome-setup],
also in Rust and also using [systemd-repart]
- Looks promising, we can probably use that once it's there
- In the meantime, can use the [systemd-sysinstall]
- Have it working for the latest Spectrum pin of Nixpkgs
- Demi: The [GNOME] project has a history of focusing on their needs
- Alyssa: We've spoken to them about whether they're open to
contributions not strictly related to GNOME and got positive
feedback
- Also it's only one or two people there, and they seem to be
receptive to accommodating us.
- [GTK] appeared less flexible
- Alyssa: That is a much bigger project
[gnome-setup]:
https://gitlab.gnome.org/Teams/STF/setup
[systemd-repart]:
https://www.freedesktop.org/software/systemd/man/latest/systemd-repart.html
[systemd-sysinstall]:
https://www.freedesktop.org/software/systemd/man/devel/systemd-sysinstall.html
[GNOME]:
https://www.gnome.org/
[GTK]:
https://www.gtk.org/
- Demi:
- Making device backends run on the host
- Linux assumes that every USB device (and hardware in general) is trusted;
it's just not considered a security issue that a USB device would
do arbitrarily bad things, such as taking over the kernel
- Example: https://access.redhat.com/security/cve/cve-2024-50302
- ChromeOS and Android would like otherwise, but Google hasn't
paid anyone to go over the Linux USB stack to find
vulnerabilities (they could but don't)
- So essentially you can take over the kernel with a compromised
device
- But we want the system to be robust against vulnerable drivers
- Linux is important because it runs a lot of hardware, not because
it's particularly secure or well-designed
- The goal of Spectrum is to make it secure but also to make it
look like a sufficiently normal system to processes
- Qubes is secure, but isn't particularly normal
- The ideal is a [capability-based operating system], and Spectrum
is the minimum viable increment over the current state of
affairs
- One long-term goal is to expose hardware via VMs, and that
requires a communication mechanism between these VMs in the
first place
- The protocol would be [virtio-vhost-user],
see also the [issue on virtio-vhost-user support in Cloud Hypervisor]
- Have been working to get the spec and implementation over
the finish line
- Updated the spec
- Eventually this might risk becoming co-maintainer of a lot
of virtio drivers for different device types (block
device, microphone, camera, ...), but even with insecure
drivers there's also a degree of protection of hardware
against malicious apps
- The benefit would be that the physical device never comes into
contact with the application, and the scope of a vulnerable
driver would be constrained to just the VM handling the device
- Network is easier, because networking is by design able to be
routed between multiple VMs
- Exposing [virtio-gpu] 3D acceleration
- People want to run graphical applications efficiently
- Short of passing through the entire GPU (which would limit us to
only one VM being able to access it), the best we can do is
virtio-gpu native context
- Context on that is worth a full talk:
[Reasonably Secure GPU Acceleration at Xen Project Summit 2024]
- Lilla: Heard that [ChromeOS is deprecating graphical acceleration]
- Demi: Know that they got rid of it on Intel devices, not sure
about ARM
- They added a note on their website that it's still available but
unsupported
- Demi: That may have been specific to platforms that don't have
native context
- Alyssa: found this [note on Reddit mentioning virgl];
emulated OpenGL is hard to do securely
- Demi: A future option could be a thing called [magma-gpu], but
that would require more upstream work on [Mesa]
- Graphics drivers are basically their own kernels; that's the level
of complexity we're talking about...
- [Control groups] in Spectrum
- Main goal is to watch resource use
- Secondary goal is shutting things down cleanly
- Normally this is done by systemd, but Spectrum doesn't use systemd
after evaluating it (should be in an FAQ)
- Main remaining issues:
- No locking for concurrent operations on a cgroup tab
- Found a way to do it recently
- You get a deadlock on an empty cgroup
- You can't even kill it and the network locks up, no idea why
- Still work in progress
[capabililty-based operating system]:
https://en.wikipedia.org/wiki/Capability-based_operating_system
[virtio-host-vuser]:
https://inbox.spectrum-os.org/spectrum-discuss/878s4i3ixs.fsf@alyssa.is/T/
[issue on virtio-vhost-user support in Cloud Hypervisor]:
https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7045
[virtio-gpu]:
https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html
[Reasonably Secure GPU Acceleration at Xen Project Summit 2024]:
https://youtu.be/FrKEUVB-BYM
[ChromeOS is deprecating graphical accelleration]:
https://developers.google.com/chromeos/app-development/develop/news#:~:text=deprecated%2C%20are%20no%20longer%20supported
[note on Reddit mentioning virgl]:
https://www.reddit.com/r/chromeos/comments/1mzim3e/is_it_technically_possible_to_use_gpu_in_chromeos/?solution=c6f8bbdad1b0bf7ec6f8bbdad1b0bf7e
[magma-gpu]:
https://github.com/magma-gpu
[Control groups]:
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cgroups.html
- Valentin:
- Working on Spectrum documentation
- Recently changed the rendering to display all of the material in
the same style
- Updating things for readability and discoverability in small
increments
- What do people expect from documentation?
- Interested in any input! What would help you get going, e.g. with
contributing?
- Everyone is invited to introduce themselves and share work related to
Spectrum!
## Questions
None today.
^ permalink raw reply [flat|nested] 5+ messages in thread