# Spectrum Bugs and Upcoming Projects Help appreciated! [#spectrum:fairydust.space](https://matrix.to/#/#spectrum:fairydust.space) for questions. ## Bugs In addition to the bugs listed here, bugs affecting Spectrum that have been reported to the appropriate upstreams are listed in the "Help wanted!" column on the [Upstream bug/patch tracking](https://cryptpad.fr/kanban/#/2/kanban/view/yLtGXWLV6U7X5+Z1ay+oXKZMrSacqQe+51nXZYRh3ck/) board. ### Errors when powering off a network client ``` cloud-hypervisor: 81.350228s: <vmm> ERROR:vmm/src/lib.rs:1638 -- Error when removing device from the VM: DeviceManager(UnknownDeviceId("")) [ 81.945102] br1058: port 1(client1058) entered blocking state [ 81.945342] br1058: port 1(client1058) entered disabled state [ 81.945580] client1058: entered allmulticast mode [ 81.945784] client1058: entered promiscuous mode Error running command: Server responded with an error: InternalServerError: Error from device manager: UnknownDeviceId("") run: cleaning up router tap: Protocol error ``` ### Networking doesn't work when testing VMs with crosvm Did this ever work? ### Networking should be IPv6-based, but isn't ### Stop using deprecated `--socket` option for `crosvm device gpu` Should use `--socket-path` instead. ### release/checks/wayland fails if KVM is unavailable Cloud Hypervisor inside the NixOS test gets stuck in the first `KVM_RUN` call, if the test is being run in QEMU without KVM. QEMU bug? ### Make flicker-free boot work more reliably in the installer systemd messages are sometimes displayed in the installer in between Plymouth exiting and cage starting. Reproduce some of these messages, and figure out what we need to set to disable them. ### start-vmm tests don't test GpuConfig ## Upcoming projects (If we can find somebody to do them. Are you interested?) ### Look into Integrity Policy Enhancement LSM Apparently this enforces that executables must be authenticated by dm-verity. Could we use this? ### Cloud Hypervisor: support interrupt remapping inside x86_64 guests To reduce host attack surface, it would be nice to be able to move drivers into guests. Unfortunately, doing that (on x86_64) as things stand would be a significant net reduction in security. Currently, to use VFIO inside a Cloud Hypervisor guest on x86_64, it's necessary to set the "allow_unsafe_interrupts" option on the vfio_type1_iommu driver. This has all sorts of horrible potential [consequences](https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf). In Spectrum's intended use, this would very likely allow a VM providing a device to another to completely compromise the client VM. This is because Cloud Hypervisor only supports virtio-iommu, and virtio-iommu does not support interrupt remapping. (virtio-iommu was mostly designed for ARM, and on ARM the IOMMU is not responsible for interrupt remapping.) This isn't a problem for QEMU VMs, because in addition to virtio-iommu, QEMU can also emulate intel-iommu or amd-iommu devices, so those devices are generally used when VFIO is needed in x86_64 QEMU guests. Potential fixes are: #### Add support for interrupt remapping on x86_64 to virtio-iommu The author of virtio-iommu [sounds amenable to this](https://lore.kernel.org/qemu-devel/6df66b15-a9f1-fe3b-c89d-19c2e1db464c@arm.com/), but nobody has done it yet. > So if we want the virtio-iommu to be adequate for the x86 world as well, we'll probably need rudimentary IRQ remapping support #### Add support for intel-iommu to Cloud Hypervisor This might be a tough sell, since [only supporting virtio-iommu was a deliberate choice for Cloud Hypervisor](https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/iommu.md#why-virtio-iommu): > The Cloud Hypervisor project decided to implement the brand new virtio-iommu device in order to provide a virtual IOMMU to its users. The reason being the simplicity brought by the paravirtualization solution. By having one side handled from the guest itself, it removes the complexity of trapping memory page accesses and shadowing them. This is why the project will not try to implement a full emulation of a physical IOMMU. But perhaps it could be argued that virtio-iommu is not currently fit for purpose on x86_64. --- Either solution is fine for Spectrum as long as it's upstreamable. ## In-progress projects ### Customisable COSMIC _This is being worked on by yu-re-ka!_ We plan to use the [COSMIC](https://github.com/pop-os/cosmic-epoch#cosmic-comp) compositor for Spectrum. It is written in Rust, and it looks like it's targeting a good balance between wide usability and configurability. Spectrum's compositor has some requirements that wouldn't make sense for upstream COSMIC. For example, we'll want to implement some sort of clipboard permissions system, and we're likely to want to do some sort of custom window decorations, maybe like Qubes does. Maintaining a fork of cosmic-comp wouldn't be sustainable, so what we need is some way to customize the compositor's behaviour without needing out-of-tree patches. This could work by having cosmic-comp export a library that allows inserting hooks for things we might want to customise. Then we could write a very small program that used that library, set up whatever hooks we wanted, and then just told the library to run the compositor. Quick sketch: ```rust use cosmic_comp::{Hook, add_hook, run}; fn main() { add_hook(Hook::Paste, |ctx| { // ... }); run(); } ``` Upstream is on board with the general concept. Doing it this way would mean the only code we'd have to maintain would be Spectrum-specific, and we wouldn't have to worry about running into merge conflicts forever. Once this is done, we can do things like implement security contexts in cosmic-comp. It wouldn't make much sense to do that first, because it wouldn't be used anywhere. ## Upstream bug/patch tracking Upstream bugs and patches that are important to Spectrum are tracked in a [kanban board](https://cryptpad.fr/kanban/#/2/kanban/view/yLtGXWLV6U7X5+Z1ay+oXKZMrSacqQe+51nXZYRh3ck/). These are patches to upstream projects that are blocking some aspect of Spectrum development. (This usually means there's code sitting on Alyssa's laptop just waiting for these patches.) Generally, to avoid accumulating patches, in Spectrum we prefer to wait for a patch to be accepted upstream before we include code that's using it. We also prefer to wait for the commit to make it into a release, and the release to become available in Nixpkgs, to avoid the extra work that comes with overriding a dependency, and then cleaning up the override later.