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 92C18B79C; Fri, 31 Jul 2026 17:34:40 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 6763DB788; Fri, 31 Jul 2026 17:34:38 +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_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) by atuin.qyliss.net (Postfix) with ESMTPS id 43477B748 for ; Fri, 31 Jul 2026 17:34:36 +0000 (UTC) Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 286F614000EE; Fri, 31 Jul 2026 13:34:34 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Fri, 31 Jul 2026 13:34:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1785519274; x=1785605674; bh=676F3Uw9Ux WpQ1M5hxY1tXL7p/Z+1XtwnxiZ3KOrt1c=; b=aquuLJO2Ft/uLo4WRwBTD0/Ke+ KFacN4cS3tz4ag0oedhlOtdVyII4QF4lZOBv+UuVkX1s2/4mj96yLlUrBea/gj8G ckleco67VEGOgTWD99ZP9b/ZLYP6BKFssPeDfqh3gctBhPqBhwIwd+MwnQGvLhhM FgbfrSrCpV5gBnUxJ/9bTcy7IHU7B56rOAlda5sbzxTPT5yJ2dlmg77T6MJOjAS7 rtdSqtdsRInRjPh4CSMLvFEfpw5XYywBPB5tkZpjxMzZ//MrVbEMlDy0Bfwi1AKX 8HUzYtI+dHAoQuIPqxaY9SMKcIV9VcRrVpGIxdtJ3BGmlFbQTVL16aO35g6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1785519274; x=1785605674; bh=676F3Uw9UxWpQ1M5hxY1tXL7p/Z+1Xtwnxi Z3KOrt1c=; b=cDVPSRLOb8+wDlbfOSO9tQoNtfUyb1URvb1UdgGj1E1nPCzxTmm 9tnOHKj1gBfdk7iGVT4Y+g4B8ctEIy3Za+GaEQZ01etKCx4FiObnHE3D9sNIKyTd M3fuRw+3FjOuj1j8juG+K4q/ChKuYaUWPlLljKuIznXAraH9zwP0472ct9QldEHB guG7yaySN6d4mnZJv4IHt0TklD6bxZqWKo1OXMa7TxkauLD4qI9ikrp6EEOKapF4 171aMjcSn28BGhAvISVHJQ9Q4tBXJhh2NgYnhjlvjzFSe8eXztY2uD4hWheyIe24 FBjz6ewK30/T77+DNnsouQuMFn3JB0Nz7EQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEftJmUTmG1MkCjEewi/9kVw/QFou7cH81QyIx8az3h+UgjbdKBUpicVFYe4UdL/G YHhZWQYuFliZ5wN/Zm+ypqR0C9eZ0qXWvlVkedn55mkqBvOQgd1iy2EYTOnalBf+HQi+O1 Q3odDpYDJUGu4yIQVyHpRekKxJ2bXWBsIqEf9GHJRVj4MIOZQBXereQws1EnMdxBfiNzFq 7FtMYz9NNn23l89+1AkJ9SP8HTY5l2eaPIcZqHldeQ5u679qsGj0xrEay1NzSZTAM/KW3I Jp5CWxfZs9l1PxYN/HGF0ORmdpvIa4mu7Za979uCHpD50VI/F1i6wbBifhMEraAnKQwMd1 juBhjugn8KiQHCdmu7Fy7Ib+AGmbRgNxGw4oMIcqZWAgR78hL1cbDEZJ1QXKOUE/7vcMbR LGMb9u/laoB4bWD8wwNxfK7vjnsA5KWR5hMeHUgiMeBzugJufvoJmIOkbSWxOGg9hG23FX wdSXPoSQYW6/snG7mRY2A12L9E7LFbOMZVTNGIO0Lf4tcVNQEiIjZDpzxZ4zHai9Yx7pHI TGckTMYd4yHjPyM2npWYRMPHXpwCT3zgGXBhQMCYDy6lh84h8qLqY9lKZXgQkqfFPbWTQs q9FdErFzptDIiRbk2/Gee5y92x6KqCj+v/qgmGcv/Nzl0ncbUGi+svlyeGzg X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 31 Jul 2026 13:34:33 -0400 (EDT) Received: by fw12.qyliss.net (Postfix, from userid 1000) id 94890C60260E; Fri, 31 Jul 2026 19:34:32 +0200 (CEST) From: Alyssa Ross To: colbyt Subject: Re: [RFC] Host-to-VM attestation: proving an unmodified Spectrum host In-Reply-To: <20260730192028.1900831-1-colby@colbyt.com> References: <20260730192028.1900831-1-colby@colbyt.com> Date: Fri, 31 Jul 2026 19:34:30 +0200 Message-ID: <871pcj2hcp.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: UIQDM37TL2LN46HYDD6X6K33YJCN5GW3 X-Message-ID-Hash: UIQDM37TL2LN46HYDD6X6K33YJCN5GW3 X-MailFrom: hi@alyssa.is 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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable colbyt writes: > When reviewing the verity sub-VM series, Alyssa wrote that host-to-VM att= estation "just needs some more design thought=E2=80=A6 e.g. we could prove = to them that they're running on an unmodified Spectrum host." Here is my at= tempt at that design. It's deliberately minimal: one small host service, th= e same format used at each tier. Thank you. I think this is definitely something we're going to want and it's nice to have somebody thinking about it. > Problem > ------- > > A Spectrum VM today cannot distinguish (a) an unmodified Spectrum host ru= nning the dm-verity image the owner installed, from (b) a tampered host, or= (c) a non-Spectrum host emulating the runtime surface. Every guarantee com= partmentalization makes rests on the host, and that trust is currently impl= icit and unverifiable. > > Once a VM can verify the host: a VM holding secrets can refuse to unlock = except on an enrolled host identity; inter-VM protocols can require "both e= ndpoints on the same attested host"; and remote parties can ask a VM to pro= ve its execution environment before releasing data to it. > > You pointed out that guest-side IPE or guest self-measurement (per the ea= rlier review =E2=80=94 the guest image and its hash come from the host, so = measuring them in the guest adds nothing against the host); I will explain= 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 t= he running system, embedded in the UKI that booted. The attestation stateme= nt 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 are= 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 ho= st =E2=80=94 stated plainly =E2=80=94 but it already defeats (c) and makes = drift visible: a rebuilt or rolled-back host produces a different roothash = and the VM sees it. > > Tier 1 (measured, later): where the platform has a measurement chain (TPM= PCRs on UEFI machines; Apple's boot policy when tooling matures), the same= key is sealed to the measured boot state, so the signature additionally me= ans "and the boot chain that unsealed this key matches the enrolled policy.= " The statement format does not change =E2=80=94 only the strength of "sign= ed by." This is how systemd-creds sealing already works, so no new concepts. > > The tier is reported inside the statement; VM policy > decides what tier it requires for which action. 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? > Transport and channel binding > ----------------------------- > > The VM asks over its existing vsock control channel. vm_id is bound by th= e hypervisor-guaranteed peer CID, not by the guest =E2=80=94 > the CID is the authentication, as with the existing vsock services. The c= hallenger supplies the nonce, so statements can neither be replayed across = boots nor forwarded between VMs. 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. 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. > 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 atte= station, capability grants between VMs can carry an attested-host precondit= ion. That restates the goal of our earlier series with the host, not the gu= ests, 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 exi= sting services) that reads the active roothash and signs statements. On the= order of 200 lines. > 2. A guest library and CLI (spectrum-attest verify --require-roothash-fil= e ...) usable from unlock scripts. > 3. Install-time keygen. Tier 1 sealing arrives later with no format chang= e. > > We run the contract form of this downstream today and would implement the= Spectrum-native form upstream-first, with a QEMU integration test in relea= se/checks. > > Open questions > -------------- > > 1. Statement encoding: JSON, or the netstring style the existing control = plane favors? > 2. Should boot_generation come from the bootloader (BLS counters) or the = attestation service's own store? > 3. Key custody at reinstall =E2=80=94 is "new install =3D new identity, V= Ms re-enroll" acceptable v1 semantics? (I think yes: it makes reinstalls vi= sible, which is the point.) 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCamzcpgAKCRCZddwkt31p FZuuAQDh2FcF5+QIHN+IT62O2WJYUtiL8QUlj3arDDMfGmfvOQD/e1CsCZ0AojiO VXohxtqurDZom5fNAmfBJYlZrc7qmwg= =1B+o -----END PGP SIGNATURE----- --=-=-=--