Re: [PATCH RFC 17/20] attestation: Add CTLV operation handling

[Jiri Pirko <jiri@resnulli.us>]

Thu, Nov 05, 2026 at 02:52:19PM +0100, yeoreum.yun@arm.com wrote:
>On Thu, Nov 05, 2026 at 01:32:49PM +0100, Jiri Pirko wrote:
>> Wed, Nov 04, 2026 at 08:46:22PM +0100, jgg@ziepe.ca wrote:
>> >On Wed, Nov 04, 2026 at 07:11:44PM +0000, Yeoreum Yun wrote:
>> >> [..snip..]
>> >> 
>> >> > +static int attestation_evidence_request_decode(struct attestation *att, struct ctlv_op_ctx *ctx,
>> >> > +					       const struct ctlv_cursor *request,
>> >> > +					       struct attestation_evidence_request *decoded,
>> >> > +					       struct attestation_evidence_object_request **objects)
>> >> > +{
>> >> > +	const struct attestation_evidence_caps *caps = att->provider->evidence_caps;
>> >> > +	u32 challenge_length;
>> >> > +
>> >> > +	decoded->challenge =
>> >> > +		ctlv_attestation_evidence_get_evidence_challenge_get(request, &challenge_length);
>> >> > +	decoded->challenge_length = challenge_length;
>> >> > +	if (challenge_length < caps->min_challenge_length ||
>> >> > +	    challenge_length > caps->max_challenge_length)
>> >> 
>> >> Hmm, I'm not sure whether this check is required for
>> >> ATTESTATION_EVIDENCE_BLOB_EVENT_LOG blob type.
>> >> 
>> >> for example, if the provider provides two evidence:
>> >>   - ATTESTATION_EVIDENCE_BLOB_PRIMARY (might attestation token)
>> >>   - ATTESTATION_EVIDENCE_BLOB_EVENT_LOG
>> >> 
>> >> might challenge is reuiqred for generating the token
>> >> and this would be marked at min/max_challenge_size in evidence_cap.
>> >> 
>> >> However, in case of eventlog, it wouldn't require challenge.
>> >> for example, TPM event log or CCEL event log.
>> >
>> >Right
>> >
>> >> Do we need some field on attestation_evidence_supported_object whether
>> >> it requires challenge or not and applies this sanity check per the object?
>> >> 
>> >> Otherwise, to get eventlog, it would need to send *dummy* challenge
>> >> always.
>> >
>> >I wonder if we should have two interfaces here for signed and unsigned
>> >evidence? It would be clearer for userspace then when it needs to
>> >provide a challenge or not.
>> 
>> Isn't the challenge field provided/not-provided enough?
>> 
>> Currently on the introspection side, device-get op would provide
>> challenge-lengths array:
>> 
>>         evidence?:
>>           challenge-lengths[8]:
>>             length?: uint(..4096)
>>             min-length?: uint(..4096)
>>             max-length?: uint(..4096)
>>  	  objects[16]:
>>             blob-class: evidence-blob-class
>>             max-length: uint
>>             blob-instance?: uint(..u32-max)
>> 
>> I think it would make sense to have challenge-lengths array per object:
>> 
>>  	  objects[16]:
>>             blob-class: evidence-blob-class
>>             max-length: uint
>>             blob-instance?: uint(..u32-max)
>>             challenge-lengths[8]:
>>               length?: uint(..4096)
>>               min-length?: uint(..4096)
>>               max-length?: uint(..4096)
>> 
>> Then the unsigned object would just simply have challenge-lengths empty?
>
>This looks good to me. :)

The challenge is one of several open points that all depend on what an
evidence object is: Rick's TDREPORT, legacy versus DICE Quotes,
"primary", "raw" and the format strings. Here is my proposal to settle
these together:

The model:

1. device-get lists each object with an id, a class (signed, event-log,
   cert-chain or auxiliary), the formats it may come in, its max-length
   and, for signed objects only, challenge-lengths.
2. evidence-get names objects by id, as MR ops name MRs, each with its
   output blob. It carries a challenge exactly when it names a signed
   object, and the challenge has to fit each of them.
3. The reply gives each object's format, length and, where the TCB
   vouches for it, the TCB's digest. The output is always {label, data}.
4. A signed object is made by the call, over the challenge, and never
   reused. The rest are read as they stand.

This settles following issues discussed during this patchset review:

1. One op, not two. Per-object challenge-lengths tell userspace when to
   pass a challenge, and one call returns the signed object with the log
   and certificates needed to check it.
2. TDX's TDREPORT goes: it is MAC'd for the platform, not signed.
   /dev/tdx_guest keeps TDX_CMD_GET_REPORT0.
3. TDX's Quote object lists the legacy and the DICE format. The provider
   labels what the host returned and fails on a Quote it cannot label.
4. "primary" becomes "signed", manifest joins auxiliary, spdm-vca,
   spdm-measurements and tdisp-report become formats, and signature
   goes, as a signed object carries its own.
5. "raw" goes with the representation attr. The TCB digest is a reply
   field, so a blob always holds the object's own bytes.

Formats become an enum each provider family defines, instead of free
strings. I'm still unsure if format should be entirely provider-specific
and defined as "extension", or it should be somehow mixture of common
and provider-specific. Looks there is not really much common
anyway, so I lean towards provider-specific only. So far I have:

======  ============  ==========  =========  ===========================
Family  Format        Class       Challenge  Bytes
======  ============  ==========  =========  ===========================
tdx     quote         signed      64         Intel TDX DCAP Quote
tdx     quote-dice    signed      64         DICE-based TDX Quote
tdx     ccel          event-log   none       ACPI CCEL log area, a TCG
                                             crypto-agile event log
spdm    cert-chain    cert-chain  none       SPDM certificate chain,
                                             instance = slot 0-7
spdm    vca           auxiliary   none       SPDM version, capabilities
                                             and algorithms transcript
spdm    measurements  signed      32         SPDM GET_MEASUREMENTS
                                             response
spdm    tdisp-report  auxiliary   none       TDISP interface report
tpm     quote         signed      varies     TPM2_Quote's attestation
                                             structure and signature
tpm     event-log     event-log   none       TCG PC Client crypto-agile
                                             event log
tpm     ek-cert       cert-chain  none       EK certificate from NV
armcca  token         signed      64         CCA attestation token,
                                             platform and realm parts
armcca  event-log     event-log   none       Realm firmware log, if any
snp     report        signed      64         SNP attestation report
snp     cert-table    cert-chain  none       VCEK or VLEK, ASK and ARK
======  ============  ==========  =========  ===========================

Did I miss something that would break us here?

CTLV layout draft:

    device-get reply, caps.evidence:
      objects[16]:
        id: uint(..15)
        class: evidence-class
        # The reply says which one was written.
        formats[4]: evidence-format
        max-length: uint
        # Signed objects only, entries as today.
        challenge-lengths[8]?: ...
        # Descriptive, such as an SPDM slot.
        instance?: uint(..u32-max)
        # When the TCB vouches for the object with a digest.
        tcb-digest-algo?: hash-algo

    evidence-get request:
      # Required exactly when a signed object is named.
      challenge?: binary(1..4K)
      objects[16]:
        id: uint(..15)
        data: blob(out, va memfd dma-buf)
      # selection, privlevel, service and options as now.

    evidence-get reply:
      # In request order.
      objects[16]:
        format: evidence-format
        length: uint
        tcb-digest?:
          hash-algo: hash-algo
          data: binary(16..64)
      # The generations as now.

Makes sense?