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

[Mario Limonciello]

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?
>
> 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.