Recent Patch Submissions -> Future Patch Submissions

[colby@colbyt.com]

Most can probably safely ignore this email, its just my personal background and what I'm interested in and why

TLDR: The patches I sent are just all the pre-reqs that were necessary to get Spectrum to boot on native Apple hardware, plus anything I saw on your bug page.  My thought was to build an experimental/protoype security distribution on Spectrum with a novel vm orchestration/security framework and baremetal rust VMs.

Long Version:

Alyssa based on your emails about my commits -- I suppose I should zoom out and give some background context so you understand where I'm coming from/going to, and can maybe offer some guidance to make my time more useful. My apologies for the length.

Background / Why I'm interested in Spectrum:

I historically come from the field of AI and security and don't do OS dev. Nor is being a developer my day job these days. 

I have done a lot of trying to protect human rights activists from nation state cyber in authoritarian countries, and work with a variety of orgs that do things like that. I also have been referring open source maintainers to frontier AI companies for security review the last year (prior to the announced programs), and all that has me more urgent on new cyber security paradigms for living in an AI intrusive world.  I am hoping to experiment on top of spectrum.

For security purposes, I am currently relegated to mac m5 devices with memory integrity enforcement and lockdown mode on laptops - or grapheneOS on Google pixel for a phone.  My open source laptop/desktop options are not so good, and spectrum feels like the right shape of an answer.  I am trying to see if it would be feasible to make that happen in a relevant time frame.

Zooming further out - I have been interested in making an operating system somewhat spectrum'ish for many years now, or rather "having there be one that exists and is good somehow", and trying to donate to it.

That started with having the people I support use Google chromebooks for security (and noticing crosvm) and knowing these people needed but would never use Qubes. I made several proposals to fund developers with various org money and wrote a lengthy OS proposal doc to a few, but an OS is a huge quagmire of a project to build and maintain as I'm sure you know better than me, and I never found the right people.

Relatedly I was a relatively early grapheneOS user/supporter and anon contributor and wrote and funded some setup guides and materials, and was excited to see their progress.  I wanted to see a properly designed open source desktop OS that would succeed on that level and run on broad hardware with compartmentalization and security orientation. I proposed something like spectrum to them in an email a few years ago, which they supported conceptually but were not willing to take on (a crosvm compartmentalized desktop OS using their security hardened chromium called vanadium + a highly containerized version of chromeOS).  Inevitably I eventually came across Spectrum, poked my head in, though saw it was still small -- but I really liked the dedication and upstreaming, and the actual platform choices were the closest of any project to what I had in mind.

Actions:

I sent $5k to Spectrum back in March and wrote a little blog note https://goodancestor.com/polymeros-collaboration-proposal-2/

Whenever I give a grant I also like to help projects, and so last week I looked at Spectrums' bug list and tried to see if I could fix some/all the things on it as a way to learn about the repo and understand its possible platform limitations.

Future Directions:

I have a bigger vision though than bug fixes -- which I think could be very spectrum aligned/enabled.

Bare metal Rust/GO VM appliances and inter-vm security atttestation/permissions leases:

I was just speaking at cyber security conference in Berlin and was on a panel with this guy, and we were talking after about the future of operating systems and I mentioned the future looked less like out of date linux devices everywhere and more like formally verified bare metal security code in modular containers - something more like Tamago for the USB Armory (arm security device) - you don't need to run an entire linux kernel for everything.. and he mentioned he had worked on a bare metal rust image for usb armory (arm) 6-7 years ago.  So I modernized that, and got it working again, and worked on adding things like network support.  While I was looking at Tamago, I realized it worked with cloud hypervisor, and then I saw a picture take form and decided I needed to know if it would work in spectrum, and port it from go to rust. These little security containers could be spectrum keystores and things, as part of a larger set of userland VMs and security protocols -- which form the core part of my intended OS design that I was thinking to build with it - which I've been calling Polymer.

I decided to give myself a week all in to dig into this stuff and see how far I could get building an custom security OS distribution on top of Spectrum, to decide if I would continue to poke that direction and to understand if it was feasible.  Realistically this is a 5% time thing for me.

For it to be useful for my purposes security has to be really good, so I went straight for the IPE/kernel updates, and aarch64 to see how far that was going to go.

Native Apple Boot / ARM64

I also decided for install base reasons I had to make it native boot on apple hardware, which I achieved last week (mac studio m2, macbook air m2).  The patches you are seeing are just all the changes I had to do working backwards from that goal, which required a newer kernel and the newer kernel and bug fixes required updating nixpkgs.

So wow that was an adventure, for you probably a yawn knowing what's going on with all this stuff, but I had no idea what I was doing here with any of these tools.

The other thing I went really hard towards are the OS containers and a security model - I haven't sent those patches, because they are not nearly baked and are total chaos, and also its unclear which belong in spectrum vs, this experimental OS/distro i'm trying to hack on top of spectrum.  But I am happy to discuss that if you find them valuable.

But long story short I have not slept in a bit, so please forgive any confusions or oversights.

I realize now I should have reached out before just plowing ahead on random bugfix tasks some of which you have already done and are just not in the code base yet (as it says clearly on your website is likely to be the case).

My intent would be to drop some major features, probably in a forked repo or something, and to binge work on this super sporadically in fits as my attention allows. Right now I'm kind of hooked, but then I disappear for long periods of time working on other projects and things.

If you are motivated, I am happy to hop on a realtime voice/video/text or whatever and hash through things so my work benefits your goals, but I know you have had a concrete vision a long time and I generally do not want to derail that (which is why I just tried to send back helpful patches and not spam your comms with my ideas).

Relatedly since you mentioned having trouble keeping up with nixpckgs lately, I sent you all the patches to get to nix latest that I thought would be useful.  That includes the earlier patches I sent in that direction for cloud hypervisor.. I now have a total mess of experiment branches, so I need to try to clean this up somehow, and will probably base around linux-latest nix / 7.1.1 myself but figured the project would want to stay on 6.18 LTS but have the .36 vs .2 security updates, so I added a patch for that too.

Probably the biggest question for me now is if I should try to do work on cosmic 1.1 (I started to a bit).  Nixpkgs is not up to 1.1 yet.  It sounds like maybe you guys have a lot of plans / things going with cosmic already.  I saw the patch you had upstreamed listed on your website had already been adopted, though I still had to patch epoch to have a fixed address to communicate with cosmic to get it in.

Do you have any existing vision documents or code you'd want me to work from to progress that in a way that would be useful to spectrum. Should I just plow ahead and play around with it? (update you told me you have a branch)

If not that I can go back to 1) building the os model and security appliances for polymer that I think would be most useful for spectrum first 2) go further down the native apple build and boot path for installing from mac / asahi and all that annoying stuff

Regarding the recent patches to nix latest -- I should probably also state that I MEANT to test everything on AMD64 but builds take so long that I haven't gotten around to it yet, so everything is tested on aarch64 (this mac studio running asahi linux).  I started setting up a nice AMD64 build box today with 64 cores, so hopefully in the future I can test across platforms on low effort.

I am doing like 72 other things so I really apologize that I am likely to be bit hazardous and scatterbrained about my contributions, but I would like to try to help.  I think this is a really promising architecture to base from.

On Friday, June 26th, 2026 at 7:06 AM, Alyssa Ross <hi@alyssa.is> wrote:

> colbyt <colby@colbyt.com> writes:
>
> > Update Spectrum's patched Cloud Hypervisor package to 52.0 and rebase
> > the local virtio-gpu/vhost-user GPU support onto that release.
> >
> > Cloud Hypervisor 52.0 uses vhost 0.16.0 and vhost-user-backend 0.22.0,
> > so update the paired rust-vmm/vhost checkout as well.  The local vhost
> > shared-memory patches are no longer applied because vhost-user-backend
> > 0.22.0 already has the protocol support used by the GPU frontend.
> >
> > The cargo vendor derivation now vendors dependencies after applying the
> > local Cloud Hypervisor and vhost patches, so the patched vhost checkout
> > is included in the fixed-output dependency tree.
> >
> > Signed-off-by: colbyt <colby@colbyt.com>
> > ---
>
> For Cloud Hypervisor 52.0, my plan had been to drop the custom GPU
> device, and just extend the new generic vhost-user device Demi
> upstreamed to support SHMEM, reducing the divergence with upstream and
> easing the path towards upstreaming the rest.  I have this version of
> the patch locally, but had been waiting for the Nixpkgs update that will
> bring in the new Cloud Hypervisor.  I expect that Nixpkgs update will
> come in the next week or two, after the next Nixpkgs staging cycle
> (which will bring some package fixes we need).  Keeping Nixpkgs up to date got
> away from me this year so far, because I was focused on some big
> organizational/long-term things for the first few months (that I hope
> will visibly bear fruit shortly…), but I've been back on it in the last
> few weeks getting Nixpkgs back into shape, so it should be back to
> regular updates shortly.
>
> If you'd like though, we could decouple our Cloud Hypervisor version
> from Nixpkgs' like you've done here, and I could update Cloud Hypervisor
> to 52.0 with my patch to extend the generic vhost-user device, rather
> than waiting another week or two for the Nixpkgs update.  What do you
> think?
>