Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Nov 11, 2026 at 01:09:43PM +0000, Reshetova, Elena wrote:
> > 
> > On Tue, Nov 10, 2026 at 01:15:06PM +0000, Reshetova, Elena wrote:
> > >
> > > > On Mon, Nov 09, 2026 at 01:54:57PM -0700, Dave Jiang wrote:
> > > > > > Why? Seems like another wasted operation..
> > > > >
> > > > > The TDX module runs it as part of the connect and with the current
> > > > > module the host can't skip it. I'll discuss with Elena and see if
> > > > > this can be different.
> > > >
> > > > Does it come out anywhere and become visible to the host or guest?
> > >
> > > Yes, it is visible to the host kernel as part of the initially returned
> > > SPDM_DEVICE_ATTESTATION_INFO_T structure. The guest can get the
> > > reference hash of this structure from the TDX Module/TSM.
> > 
> > That's security broken.
> > 
> > The guest must never see a measurement from *before* the guest did
> > LOCKED.
> 
> While I also personally prefer to do measurement checks after LOCK
> (being a security person, you tend to be pessimistic and require strictest), 
> I dont think anything in TDSIP standard says that LOCK formally affects
> measurements. The measurements tell what device/firmware is.
> It is the TDI report that tells it how this particular TDI has
> been configured and locked for assignment.

No, LOCK says the hypervisor can no longer tamper with the device. It
revokes hypervisor access to MMIO registers. Taking a measurement and
then allowing the hypervisor change measured state via MMIO is
entirely security unacceptable.

Exactly how LOCKED works is device specific, but from a security POV
the device must implement LOCKED in a way that excludes a malicious
hypervisor from undetectably tampering with the device.

This is not statement about device firmware integrity, but about the
device *runtime* state.

For example, if the hypervisor tells the device to do a DMA write
after 1 second and then the guest attests and accepts this device
while that command is active, all guest security is lost.

The device's security design is responsible to prevent these kinds of
attacks one way or another. LOCKED is a key part of how the device can
do that.

Broadly there are three device implementation options:
1) A TDISP device MMIO is simply entirely inoperable by hypervisor and
   only works under locked. Trivial
2) Entry to LOCKED cleans the device so it is quieted down enough to
   be safe
3) Measurements record if the hypervisor did anything with the device
   before it was LOCKED.

We cannot know what kind of device we have so the OS must always
collect fresh evidence to support option #3. Or at the very least the
verifier must be aware the evidence is pre-locked and stale.

> Again, you establish a trust in a device at the time of SPDM
> connect.

This only establishes a tunnel to device firmware. It says nothing
about what the device is doing.

The CC locked/measure dance is establishing what the device is doing
at the moment it is allowed to be dma enabled'd.

> Guest can inspect VCA and the cert chain for selected SPDM authentication
> slot that was fixed during SPDM connect and decide whenever it trusts
> this device or not. This decision *might* require to know what are device
> measurements at the time of connect also. This can be needed if guest's
> trust in this device depends on its current measurements, i.e. I trust
> device A with a key B certified by a trusted intermediate C but only if
> its firmware measurement SVN is higher than 12 (because I am aware
> that device manufacturer reported a critical security bug in SVN 11). 
> If all these connect time checks are satisfied, guest can trust the device
> *given that manufacturer specified that runtime downgrades of SVN are
> not allowed* not to downgrade its measurements between SPDM connect
> and LOCK, moreover it can trust the device not to downgrade measurements
> while it stays alive (and while corresponding SPDM session stays alive). 
> So, the fact that SPDM session stays alive in this case would also guarantee
> security.

> Do you see the logic in this reasoning? 

IMHO you have focused too much on the device firmware state and not
enough on the runtime state and the impacts the host can have over the
device while its MMIO is under the control of the hypervisor.
 
> > The entire security argument of the guest is that it locks the device
> > so the host cannot tamper with it. Collects a post-lock measurement to
> > show what state it is in after locking, then makes a policy decision.
> 
> Formally measurements of the device can change even after LOCK if you
> dont explicitly forbid this via LOCK_REQUEST flags.

Yes, but this is something else entirely. We told the device it is
LOCKED so it activates all its defenses against hypervisor
tampering. We take a clean measurement to prove the hypervisor hasn't
left anything behind in the run time state. Now we trust the device
itself to only alow measurment changes that meet its own security
model and the hypervisor cannot interfere. (bugs excluded)

> > Capturing a measurement at SPDM session startup, while in unlocked, and
> > then using TDX module to trick the guest into accepting it as a
> > post-locked measurement is *entirely* unacceptable and I will oppose
> > anything like that in Linux.
> 
> There is no tricking, it is specified in TDX that these measurements are for 
> SPDM.Connect time and not after LOCK. And if you want to have later
> measurements, then you must use recollection functionality. 

I'm am feeling against even exposing early unlocked measurements to
userspace, given how dangerous it could be to ever rely on them.

> > The guest must be able to affimitively say that a fresh measurement
> > was collected after locked and when it gets the reference hash it
> > needs to know it is fresh after locking.
> 
> If it wants this, then it must do recollection and we provide this
> functionality. What is missing from this currently is TDX module does
> not refresh the reference hash because the assumption currently
> is that the same key must be used to sign recollection measurements
> that was seen during SPDM connect (and protected by a reference
> hash).

I pointed this out already, this is obviously very bad. Loosing the
direct binding to the SPDM session is a significant security
degradation compared to every other architecture for no purpose.

Updating the digest means that the guest nonce ends up being captured
by the hypervisor and presented to the next VM as the 'initial'
connection measurement. This does not seem like a good choice to me.

ARM's VM boot time mode selection of 'TSM controls nonce' or 'guest
controls nonce' works better, IMHO.

But two digests 'initial' and 'latest this guest collected' might be
the better option.

Jason