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 Thu, Nov 12, 2026 at 12:48:42PM +1100, Alexey Kardashevskiy wrote:

> >  It revokes hypervisor access to MMIO registers.
> 
> TDISP's RUN does but CONFIG_LOCKED does not so MMIO and DMA work as
> before, until RUN.

I mean the device needs to secure itself, whatever that means for the
device. Obviously the hypervisor cannot be tampering with it while we
are trying to accept it. So the device might choose to fail all MMIO
while LOCKED or something like that.

LOCKED and RUN both clearly mean the device is under guest control and
the device needs to respond to this by protecting itself from the
hypervisor.

Again, my reference threat is the hypervisor programs the device to do
DMA after 1 second and then tricks the guest into doing DMA
ENABLE. This must be prevented by the guest and device co-operating.

For a concrete example, imagine a RDMA NIC. The hypervisor boots it up
and establishes a remote QP with RDMA access to all memory. Passes it
to the guest and the guest does DMA ENABLE. Hypervisor suspends the
guest immediately after and rewrites all its memory via the network.

Devices MUST have protections against these kinds of attacks built
into their LOCKED/RUN state transitions and verification, somehow. No
spec says how to do this.

Pretty much any device that does DMA can be tricked into doing
something like this :(

> > 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.
> 
> The device fw updates (if permitted) during LOCKED/RUN won't be
> detected by the VM but it is not tampering as we trust the device to
> not accept a bad fw?

Yes. If you allow live update then you have take the position that any
acceptable measurement is going to evolve into other acceptable
measurements behind your back.

> > 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
> 
> We run the attestation without a bound driver now so the device is
> quiet but so far PCIe TDISP did not require this.

There are many things the specs don't *require* but have to be done in
a certain way to get security. Enabling dma and binding a driver
before taking a measurement is obviously security wrong.

> > 3) Measurements record if the hypervisor did anything with the device
> >     before it was LOCKED.

> > 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.
> 
> But measurements do not include the run time state (the TDI report
> does), where is this coming from?

Who says this? The measurements are defined by the device, they will
contain what the device needs to prove it hasn't been tampered with.

If the device chooses #3 then they must report some runtime state.

You both seem to have the wrong idea what is in the measurement
reports in real devices. It is not just a hash of the running
firmware..

> > Now we trust the device
> > itself to only alow measurment changes that meet its own security
> > model and the hypervisor cannot interfere. (bugs excluded)
> 
> Opposed to what, accepting any fw if not LOCKED? :)

locked should have nothing to do about firmwre update. locked is about
taking a clean measurement and preventing hypervisor tapering.

> > 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.
> 
> Does anyone actually _present_ nonce to the guest, not just forward
> the guest-generated nonce?

Yeah, ARM has this option and Intel made a worse version..

Jason