From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 1DFE5D2FC; Thu, 02 Jul 2026 23:55:09 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id DF44AD2D9; Thu, 02 Jul 2026 23:55:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-4396.protonmail.ch (mail-4396.protonmail.ch [185.70.43.96]) by atuin.qyliss.net (Postfix) with ESMTPS id BF70DD2D8 for ; Thu, 02 Jul 2026 23:55:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colbyt.com; s=protonmail; t=1783036503; x=1783295703; bh=CFNsFBnP4Tw7THev0xDi89V4LyQC0vp69w252AvpHog=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=BccKs/3Fhl5PwIXRGqFs8r/AgTjBtHS7JWm6APtZ1rbCIlz7dfheqM1bIhUbe0/JA CE9/2C711NTk5VCjStdNBzU6v3OWWMBOrk1gJ9CoDd7Pu0/LfSqnHC0exMC7t4zcV7 j+VBp1uXpbDql7l4a05OIZzZJErMzWVXY7GDfAr7UoB+1XwLhwRwuoLyA65xnpRvF8 Ki0lLSzQt9W9vTRDkfIdDJ0m9Z5vhRzjG1nVLn4hrxnuWvucKd19bdSMy8SW9WqIEu /BPvKgESInMspGDOuX+IOMo2+sg/wUm6lkSZWgjYXANyXGyzyE+e50Olgu9l4zy1I2 pgNA4hcSOpRqQ== Date: Thu, 02 Jul 2026 23:54:59 +0000 To: Alyssa Ross From: colby@colbyt.com Subject: Recent Patch Submissions -> Future Patch Submissions Message-ID: Feedback-ID: 70977973:user:proton X-Pm-Message-ID: 743ef8ef3dbf3b11579b83c908fdbb918e4d9759 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RWMMSHIEZQU5I2RCOS2T4I5IZMZ6NTIQ X-Message-ID-Hash: RWMMSHIEZQU5I2RCOS2T4I5IZMZ6NTIQ X-MailFrom: colby@colbyt.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 g= et Spectrum to boot on native Apple hardware, plus anything I saw on your b= ug page. My thought was to build an experimental/protoype security distrib= ution on Spectrum with a novel vm orchestration/security framework and bare= metal 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/g= oing 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.=20 I have done a lot of trying to protect human rights activists from nation s= tate 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 anno= unced programs), and all that has me more urgent on new cyber security para= digms for living in an AI intrusive world. I am hoping to experiment on to= p of spectrum. For security purposes, I am currently relegated to mac m5 devices with memo= ry integrity enforcement and lockdown mode on laptops - or grapheneOS on Go= ogle pixel for a phone. My open source laptop/desktop options are not so g= ood, 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 th= at exists and is good somehow", and trying to donate to it. That started with having the people I support use Google chromebooks for se= curity (and noticing crosvm) and knowing these people needed but would neve= r use Qubes. I made several proposals to fund developers with various org m= oney and wrote a lengthy OS proposal doc to a few, but an OS is a huge quag= mire 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 contr= ibutor and wrote and funded some setup guides and materials, and was excite= d to see their progress. I wanted to see a properly designed open source d= esktop OS that would succeed on that level and run on broad hardware with c= ompartmentalization and security orientation. I proposed something like spe= ctrum to them in an email a few years ago, which they supported conceptuall= y but were not willing to take on (a crosvm compartmentalized desktop OS us= ing their security hardened chromium called vanadium + a highly containeriz= ed version of chromeOS). Inevitably I eventually came across Spectrum, pok= ed my head in, though saw it was still small -- but I really liked the dedi= cation 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://g= oodancestor.com/polymeros-collaboration-proposal-2/ Whenever I give a grant I also like to help projects, and so last week I lo= oked at Spectrums' bug list and tried to see if I could fix some/all the th= ings on it as a way to learn about the repo and understand its possible pla= tform 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/permiss= ions leases: I was just speaking at cyber security conference in Berlin and was on a pan= el with this guy, and we were talking after about the future of operating s= ystems and I mentioned the future looked less like out of date linux device= s everywhere and more like formally verified bare metal security code in mo= dular containers - something more like Tamago for the USB Armory (arm secur= ity 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 wo= rked 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 keysto= res and things, as part of a larger set of userland VMs and security protoc= ols -- which form the core part of my intended OS design that I was thinkin= g 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 f= ar I could get building an custom security OS distribution on top of Spectr= um, 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 we= nt 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 app= le hardware, which I achieved last week (mac studio m2, macbook air m2). T= he patches you are seeing are just all the changes I had to do working back= wards from that goal, which required a newer kernel and the newer kernel an= d 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 secu= rity model - I haven't sent those patches, because they are not nearly bake= d and are total chaos, and also its unclear which belong in spectrum vs, th= is 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 confu= sions 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 c= ode 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 o= r something, and to binge work on this super sporadically in fits as my att= ention 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 w= hatever 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 d= erail 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 latel= y, 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 clo= ud hypervisor.. I now have a total mess of experiment branches, so I need t= o 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 b= ut 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 c= osmic 1.1 (I started to a bit). Nixpkgs is not up to 1.1 yet. It sounds l= ike 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 comm= unicate with cosmic to get it in. Do you have any existing vision documents or code you'd want me to work fro= m 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 applianc= es for polymer that I think would be most useful for spectrum first 2) go f= urther 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 hav= en'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 t= oday 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 b= e 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 f= rom. On Friday, June 26th, 2026 at 7:06 AM, Alyssa Ross wrote: > colbyt 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 > > --- > > 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 dat= e 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=E2=80=A6), but I've been back on it in th= e 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? >