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

[Yeoreum Yun]

On Thu, Nov 05, 2026 at 01:32:49PM +0100, Jiri Pirko wrote:
> Wed, Nov 04, 2026 at 08:46:22PM +0100, jgg@xxxxxxxx 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. :)

-- 
Sincerely,
Yeoreum Yun