Re: [PATCH 0/3] crypto: ccp - two PSP init fixes, and the AMD BC-250

[Tom Lendacky <thomas.lendacky@amd.com>]

On 9/22/26 05:33, Mario Limonciello wrote:
> 
> 
> On 9/22/26 05:05, Mattia Tadini wrote:
>> On 9/21/26 10:10, Mario Limonciello wrote:
>>> Sorry; but what's the point of adding support?  You can't access the
>>> crypto engine, it doesn't run SEV or TEE, it doesn't support DBC, it
>>> doesn't report HSTI.
>>
>> Thanks for looking at it. One correction first, and the mistake is
>> mine: the cover letter is wrong about HSTI. The security reporting bit
>> is clear, but psp_populate_hsti() then asks through the platform access
>> mailbox, and on this board PSP_CMD_HSTI_QUERY does answer. With the
>> series applied on 7.2.6:
>>
>>    fused_part=1               debug_lock_on=1
>>    boot_integrity=0           tsme_status=0
>>    anti_rollback_status=0     rom_armor_enforced=0
>>    rpmc_production_enabled=0  rpmc_spirom_available=0
>>    hsp_tpm_available=0
>>
>>> It seems that the capability register isn't even populated on this
>>> system.
>>
>> It reads 0x00000002, the TEE bit and nothing else. That lone bit, with
>> no TEE behind it, is what patches 1 and 2 are about.
>>
>>> To me it appears the patch series is a lot of "fixes" to let you
>>> read.... the bootloader version.  Am I missing something else?
>>
>> Only the above. Once the device is bound, userspace gets the bootloader
>> version (fwupd picks it up as "Secure Processor", bootloader
>> 00.1c.01.02) and the HSTI attributes. Nothing more: no crypto engine,
>> no SEV, no TEE, and the firmware rejects the DBC command.
>>
>> If that is not enough to carry an ID, I understand, and patch 3 can go.
>> Patches 1 and 2 then have no reason to go in either: with the current
>> table I don't know of a shipped part that sets the TEE bit on a pspv1
>> or pspv2 function, so they would only guard against a device that is
>> not there.
>>
>> So: would you take the series with the HSTI data as the justification
>> for patch 3 (I would send a v2 with a corrected cover letter), or
>> should I drop it?

My take is to just drop it.

Thanks,
Tom

>>
>> Thanks,
>> Mattia
> 
> It will be up to Tom here.
> 
> Given HSTI attributes do get exported from platform access mailbox that
> does change the shape.
> 
> But I do think that you should spin it to a v2 for the following reasons:
> 
> 1) The cover letter is wrong (this discussion).
> 
> 2) The first patch has a Fixes tag, but it's not really a bug until you
> add patch 3.  So it's in the right place in the series but I don't think
> it should have a Fixes tag.
> 
> 3) I'm confused by your comments with TEE.
> 
> Why is the TEE capabilty set but TEE doesn't work?  Is there a problem
> with a guessed register layout or a real issue?
> 
> Rather than play whack a mole, wouldn't it be better to just clear psp-
>>capability.tee when the ring init fails?  Then you can take pspv3 layout.
> 
> 4) If you DO end up sticking to a new register layout, you said up front
> in your cover letter DBC isn't supported.
> 
> Why do you set PLATFORM_FEATURE_DBC in your platform_features then in
> patch 3?  IMV this isn't going to be a relevant feature in the BC 250.
> 
> So I think that leaves two options for you to weigh out.
> 
> A) Either take the existing register pspv3 register layout and clear the
> TEE capability when the test fails
> B) Take the new layout you proposed but don't advertise DBC feature.