Re: [RFC v2] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command

[Pratik R. Sampat]

On 5/11/26 10:25 AM, Tycho Andersen wrote:
> On Fri, May 08, 2026 at 05:10:52PM -0400, Pratik R. Sampat wrote:
>> Hi Tycho,
>>
>> Missed this one in my mailbox. Thanks for the review!
>>
>> On 5/4/26 10:32 AM, Tycho Andersen wrote:
>>> On Fri, May 01, 2026 at 11:20:51AM -0400, Pratik R. Sampat wrote:
>>>>   - failed_status (read-only): firmware-reported failure status from the
>>>>     last operation, as returned alongside the status vectors
>>>
>>> "from the last operation" is not quite right here, it looks like it
>>> re-runs the STATUS command and reports that error?
>>
>> That is correct. It runs the STATUS command and reports the status of the
>> verification operation. Probably better to phrase it as the "last verification
>> operation" instead?
> 
> Hmm, I'm not sure what you mean here. The FW spec 1.58 table 132 says:
> 
>     Command to request the firmware to return information regarding the
>     currently supported (available) mitigations, and then the verified
>     (processed and completed) mitigations. If DST_PADDR_EN is set,
>     DST_PADDR will be populated with the SNP_VERIFY_MITIGATION_DST_PADDR
>     structure.
> 
> so I don't think it has anything to do with the last VERIFY operation?
> 

Right, I had missed that. Table 133 says failure_status is the status of the
verification operation. It also looks like calling STATUS repopulates
SNP_VERIFY_MITIGATION_DST_PADDR anyway.

I am not keen on caching the result either though. For simplicity, we could just
drop the failed_status interface, log failure_status with pr_[err|warn](), and
return -EIO?

> The spec is a bit messy here, though. Table 131 mentions a
> MIT_REQ_CHECK operation, which I assume should really be _STATUS. It
> describes what the output VECTOR should be for VERIFY in table 131,
> but not what it is for STATUS. Table 132 suggests the output VECTOR is
> the list of supported mitigations, which matches what I was seeing
> when I played with this.
> 

That is a good catch! We should get that changed in spec.

--Pratik