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 8CCA6C350; Sat, 01 Aug 2026 22:01:37 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 9E90EC33E; Sat, 01 Aug 2026 22:01:34 +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,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-244117.protonmail.ch (mail-244117.protonmail.ch [109.224.244.117]) by atuin.qyliss.net (Postfix) with ESMTPS id 7133AC33C for ; Sat, 01 Aug 2026 22:01:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colbyt.com; s=protonmail; t=1785621691; x=1785880891; bh=+q/A5OdG6WaOmaJvImGC4G5fqL0F/zDBKrzVTjRu9Ro=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=WeJH5B+/Sln42owVkkicLSuN/L70q49G+4yS0Tl9CGK7FMP1E/hzdBKFmJh2GWcWZ RTAf8qpSwKRbuDwnfqhx0erOW2f7+pGf37rGnA7D9ZbT8vwsXni4N9UUXCOgw6s3KO Dnpgjt8Ifk+yTvQiPqQ3i+yLFr3XS6Z6dQhzHeiONw7GdHiqzzoVzGt1I0xOYkbeXL 3bkVZk5PgoAb8+Y0482maB5oiNYs2qMk0HkzjTkitXxOoFOzRZYAP2Zn11wiRghLZA uVUiV0tbZ6JjxEQ5T8pndDWVdTOMEhA5Y9OUiLL013L5wssFSMKsKurr2HpgDT1BGi qDmcajLr5BXOg== Date: Sat, 01 Aug 2026 22:01:25 +0000 To: Alyssa Ross From: colby@colbyt.com Subject: Re: [RFC] Host-to-VM attestation: proving an unmodified Spectrum host Message-ID: In-Reply-To: <871pcj2hcp.fsf@alyssa.is> References: <20260730192028.1900831-1-colby@colbyt.com> <871pcj2hcp.fsf@alyssa.is> Feedback-ID: 70977973:user:proton X-Pm-Message-ID: 5ae011090b8fe234de3784a1d9d4631c6292ceaa MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: AK4HCWTDDZA7W5GE7O2VFILOBSCDYGIO X-Message-ID-Hash: AK4HCWTDDZA7W5GE7O2VFILOBSCDYGIO X-MailFrom: colby@colbyt.com X-Mailman-Rule-Hits: nonmember-moderation 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 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: Thanks =E2=80=94 briefly on each point. Tier 0 vs tier 1: agreed on x86_64 =E2=80=94 Apple silicon is why tier 0 ex= ists: there is no Linux-accessible keystore bound to boot state. m1n1 measu= res nothing (no event log, no PCR analog) and the SEP has no Linux interfac= e to seal to or quote from. So I suppose it should be per-platform capabili= ty reporting - a platform reports the strongest tier it has. It would be n= ice if we had a measurement log in m1n1 (hash each boot stage, expose the l= og to the OS).=20 Prior art: agreed =E2=80=94 interface as varlink-over-vsock, which also mea= ns JSON. One property belongs in the interface description: vm_id binds fro= m the hypervisor peer CID Install: Makes sense. The roothash is a population identity =E2=80=94 every= host on a release shares it. What identifies this machine is the key, and = it belongs to the mutable user-data volume: first boot on empty state mints= the identity; wiping state visibly mints a new one and forces re-enrollmen= t, which is the property I wanted, derived from the architecture instead of= asserted. That also settles boot_generation: the attestation service keeps= its own counter in the same volume. v2 of the RFC to follow eventually with those changes included. On Friday, July 31st, 2026 at 10:34 AM, Alyssa Ross wrote: > colbyt writes: >=20 > > When reviewing the verity sub-VM series, Alyssa wrote that host-to-VM a= ttestation "just needs some more design thought=E2=80=A6 e.g. we could prov= e to them that they're running on an unmodified Spectrum host." Here is my = attempt at that design. It's deliberately minimal: one small host service, = the same format used at each tier. >=20 > Thank you. I think this is definitely something we're going to want and > it's nice to have somebody thinking about it. >=20 > > Problem > > ------- > > > > A Spectrum VM today cannot distinguish (a) an unmodified Spectrum host = running the dm-verity image the owner installed, from (b) a tampered host, = or (c) a non-Spectrum host emulating the runtime surface. Every guarantee c= ompartmentalization makes rests on the host, and that trust is currently im= plicit and unverifiable. > > > > Once a VM can verify the host: a VM holding secrets can refuse to unloc= k except on an enrolled host identity; inter-VM protocols can require "both= endpoints on the same attested host"; and remote parties can ask a VM to p= rove its execution environment before releasing data to it. > > > > You pointed out that guest-side IPE or guest self-measurement (per the = earlier review =E2=80=94 the guest image and its hash come from the host, s= o measuring them in the guest adds nothing against the host); I will expla= in why that's important later (and why I implemented it that way). > > > > The host identity Spectrum already builds is the dm-verity root hash of= the running system, embedded in the UKI that booted. The attestation state= ment is: > > > > spectrum_roothash: active dm-verity root hash > > uki_id: BLS entry name that booted > > boot_generation: monotonic per activation > > nonce: challenger-supplied > > vm_id: the asking VM, host-assigned > > > > signed by a host attestation key. Fields are additive; unknown fields a= re ignored (similar to vhost-user capability negotiation). > > > > Who signs, and what the signature means > > --------------------------------------- > > > > Tier 0 (software, day one): the key is generated at install in a > > dedicated attestation service and never leaves the machine. The > > signature means "a process on a host that booted *some* image, with > > access to this key, says so." That is weak against a fully compromised = host =E2=80=94 stated plainly =E2=80=94 but it already defeats (c) and make= s drift visible: a rebuilt or rolled-back host produces a different roothas= h and the VM sees it. > > > > Tier 1 (measured, later): where the platform has a measurement chain (T= PM PCRs on UEFI machines; Apple's boot policy when tooling matures), the sa= me key is sealed to the measured boot state, so the signature additionally = means "and the boot chain that unsealed this key matches the enrolled polic= y." The statement format does not change =E2=80=94 only the strength of "si= gned by." This is how systemd-creds sealing already works, so no new concep= ts. > > > > The tier is reported inside the statement; VM policy > > decides what tier it requires for which action. >=20 > I suppose the motivation to have tier 0 at all is that Apple stuff isn't > far enough along to go straight to tier 1? On x86_64 I expect we could > go straight to tier 1. I have a bias against investing in that sort of > transitionalism, but it's not one that can't be overcome. What's > missing on the Apple platform? Is there anything we can do to help move > it along? >=20 > > Transport and channel binding > > ----------------------------- > > > > The VM asks over its existing vsock control channel. vm_id is bound by = the hypervisor-guaranteed peer CID, not by the guest =E2=80=94 > > the CID is the authentication, as with the existing vsock services. The= challenger supplies the nonce, so statements can neither be replayed acros= s boots nor forwarded between VMs. >=20 > We should consider prior art here. I would guess that systemd probably > already has an interface for this sort of attestation. It would be good > to build on that to the extent possible, to take advantage of expertise > that has already gone into this problem, and also to potentially be able > to reuse their implementation. >=20 > I can imagine other sandboxed Linux systems might like something like > this, so we should consider whether this might (eventually) end up as a > standard portal that apps could use on any OS that implements it. With > that in mind, it would make sense for our VM-host interface to be > implemented as a varlink-over-vsock interface, since that's what the > next generation of portals is expected to use. >=20 > > What the VM does with it > > ------------------------ > > > > Policy stays with the owner, inside the VM: "unlock only if > > spectrum_roothash is in my enrolled set" is a file in the VM's > > storage. Spectrum holds mechanism, not policy. > > > > Relationship to inter-VM capabilities > > ------------------------------------- > > > > Once both endpoints of an inter-VM channel can require the same host at= testation, capability grants between VMs can carry an attested-host precond= ition. That restates the goal of our earlier series with the host, not the = guests, as the root =E2=80=94 which I think > > answers the "what does guest-side verity buy you" question: nothing > > against the host; everything between peers and toward remote parties. > > > > Implementation sketch > > --------------------- > > > > 1. spectrum-attestd: a small host service (same s6 + vsock pattern as e= xisting services) that reads the active roothash and signs statements. On t= he order of 200 lines. > > 2. A guest library and CLI (spectrum-attest verify --require-roothash-f= ile ...) usable from unlock scripts. > > 3. Install-time keygen. Tier 1 sealing arrives later with no format cha= nge. > > > > We run the contract form of this downstream today and would implement t= he Spectrum-native form upstream-first, with a QEMU integration test in rel= ease/checks. > > > > Open questions > > -------------- > > > > 1. Statement encoding: JSON, or the netstring style the existing contro= l plane favors? > > 2. Should boot_generation come from the bootloader (BLS counters) or th= e attestation service's own store? > > 3. Key custody at reinstall =E2=80=94 is "new install =3D new identity,= VMs re-enroll" acceptable v1 semantics? (I think yes: it makes reinstalls = visible, which is the point.) >=20 > I don't usually think of Spectrum has having a concept of an "install". > Since everybody runs the same image, and the read-only OS is strictly > separated from user data, I've always thought of any "install" of that > image as being equivalent. >