[Rats] Re: comments on draft-poirier-rats-eat-da-09

[Mathieu Poirier <[e-mail]>]

Good day Michael,

Many thanks for the review and thoughtfull comments.  Thomas and I
have jointly formulated the inline comments below.

On Tue, 2 Jun 2026 at 12:37, Michael Richardson <[e-mail]> wrote:
>
>
> I've read draft-poirier-rats-eat-da-09.
> I understand that it is an EAT Profile.
> The problem statement seems clear as to positive goals, but I find that I do
> understand the attack/risk of doing this wrong.
>
> Is it that the TVM is suspicious of the device (GPU, NPU), so would be
> reluctant to sends it's model/workload down to it?
> This feels like a variation of the multi-verifier and composite attester
> problem.
>
> 1. I think that a black diagram (including one or two PCIe bridges), would be
>    helpful.  Figure 1 in Appendix B... move it up.
> 2. It seems that the device attestation mechanism is meaningless without
>    some connection to the hypervisor/host attestation.

Confidential Computing does not rely on anything from the hypervisor or
the host.  The TVM uses the platform, i.e., PCIe DOE protocol, but does
so over encrypted channels.  The platform delivers the bits between the
trusted and non-trusted worlds, but all the information is encrypted.

> 3. I'm not convinced this is actually an EAT *Evidence* Profile.
>    To me, this feels like device Attestation Results that need to be
>    included in the TVW/CCC Evidence as part of it's trusthworthiness
>    evaluation.  This would be the TEEP/TAM model.
>    How is this different?
>

In some use cases, the lead attester can be co-located with a verifier
that can verify the evidence and present the DAT claims as attestation
results.  In our scenario, there is no local verifier and the DAT
claims-set is effectively evidence.

Therefore, it is probably more accurate to say that DAT is an EAT
profile for both evidence and attestation results.  This is
fully consistent with the objectives and scope of RFC9711.

> "A DAT can be used as a
>    standalone entity but can also be embedded in a larger, platform-
>    specific attestation token."
>
> Don't sit on any fences: I'd be happier if it did one or the other.
> EAT was way less specfic than I wanted, and now we have a profile that
> appears to also need a profile to be used.
>

In the use cases we are targeting, embedding the DAT in a composite
evidence is unavoidable.  However, when it is part of a wider evidence
collection, the DAT can be embedded without any further profiling.

> >3.1.1.  Measurements Claim
> >
> >   There can be up to 239 measurements per device with the entire
> > measurement log optionally signed by the certificate populated in one
>
> I'm guessing 239 = 256 - someoverhead?
> It's otherwise an odd number that probably needs a reference to explain.
>

The SPDM specification reserves measurement indexes between 240 and 256,
hence the 1..239 range.  We will clarify this in the draft.

>
> >   ; M1 /= GET_VERSION , GET_CAPABILITIES , NEGOTIATE_ALGORITHMS , \
> >                  GET_DIGESTS , GET_CERTIFICATE , CHALLENGE (A1, B1, C1)
>
> Since these are comments, can you just pre-wrap them?
> Just slightly easier to read that way.

Very well, we will adjust this.

>
> >3.1.4.  TDISP Device Interface Report
> >
> >   A TDISP Device Interface Report can only be obtained if the device
> >   interface has transitioned to the CONFIG_LOCK or RUN state of the
> >   TDISP state machine.
>
> What? state machine? CONFIG_LOCK? RUN?
> Clearly I need more background to understand this.
> At least I am intimately familiar with PCI BARs, gosh... building NPUs 25
> years ago...

The TEE Device Interface Security Protocol (TDISP) is part of the PCI
Express specification.  By way of a state machine, TDISP defines a set
of steps (along with the security requirements for each step) a device
needs to go through to be trusted by a TVM.  CONFIG_LOCK and RUN are two
of the states of the TDISP state machine where a TDISP report is
available.

Do you think the above should be added to the draft?

> Is there any concern that PCI(e) device A would be judged trustworthy,
> and then the hypervisor would then rewrite the BARs such that the physical
> address space mapped into the TVM is now on malicious device B?

Good question.

The measurements and their potential signature allow a TVM to trust that
the device FW is properly enacting the TDISP protocol.  The TDISP
protocol states that no modifications can be made to the BARs when the
device is in the CONFIG_LOCK or RUN state.  If this happens, TDISP
requires the device FW to destroy all memory allocated to the device and
return to the CONFIG_UNLOCK state.  At that point the TVM can't use the
device anymore.

> Given that PCI Functional space, (where the BARs are), is very very much
> protected against everything, I can't see how a TVM would be able to
> independently evaluate that.  Thus... the need for a strong connection up to
> the physical trustworthiness evaluation?
>

I think this goes back to the measurements and signatures obtained from
the device.  The TVM can then use these to assess the trustworthiness of
the TDISP implementation.

> 4.4 Freshness model.
> I can see how nonces would work, but in the context of PCIe, I'd think that
> Epoch IDs would need to be distributed via some kind of PCI broadcast.
>

We assume the existence of a coordinator (e.g., a lead attester) to
distribute the freshness obtained from the challenger (RP or verifier)
to the assigned devices.  The challenge can be either a nonce or an
epoch marker, but this information is opaque to the devices.  Note that
in order to work in this context, the epoch marker must be compatible
with the eat_nonce encoding requirements.

> 7. SC is missing the point.  Tell me about what can go wrong... and how we
> prevent, detect or mitigate that using the techniques described.
> It's good to reference the SC from 9711, but maybe explain for each section,
> to which part of this document they apply.
>
> >   tracking of a given workload across multiple TVM instances in both
> >   the temporal and spatial dimensions.
>

Fair enough, we will look into this.

> Good terms, but probably not manager-compatible.
> temporally:  so across reboots of a specific piece of hardware
> spatially:   so across migrations between hardware, and even between data centers
>              (e.g., outsiders know if a customer fires supplier A and move to
>              supplier B?)
>

We will clarify this part.

>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>

I lived in the Ottawa area for close to 30 years.

Best regards,
Mathieu

> **       My working hours and your working hours may be different.         **
> ** Please do not feel obligated to reply outside your normal working hours **
>
>
>
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]