[PATCH v2 4/7] arm: dts: k3-{j721s2/j784s4}-binman: Pack HSM firmware inside tispl.bin

[Andrew Davis]

On 5/8/25 10:03 AM, Beleswar Prasad Padhi wrote:
> 
> On 5/8/2025 5:29 PM, Anshul Dalal wrote:
>> On Wed May 7, 2025 at 8:53 PM IST, Andrew Davis wrote:
>>> On 5/7/25 9:56 AM, Beleswar Prasad Padhi wrote:
>>>> On 5/7/2025 3:09 PM, Anshul Dalal wrote:
>>>>> On Tue May 6, 2025 at 4:11 PM IST, Beleswar Padhi wrote:
>>>>>> Pack the HSM firmware in tispl.bin fit image so that it can be unloaded
>>>>>> and used by R5 SPL to boot the HSM core. By default, point to the
>>>>>> firmware for HS-SE device type. This needs to be changed to point to
>>>>>> appropriate firmware when using a different device type.
>>>>>>
>>>>>> Signed-off-by: Beleswar Padhi <b-padhi at ti.com>
>>>>>> ---
>>>>>> v2: Changelog:
>>>>>> None to this patch.
>>>>>>
>>>>>> Link to v1:
>>>>>> https://lore.kernel.org/all/20250422095430.363792-4-b-padhi@ti.com/
>>>>>>
>>>>>>    arch/arm/dts/k3-j721s2-binman.dtsi | 12 ++++++++++++
>>>>>>    arch/arm/dts/k3-j784s4-binman.dtsi | 14 ++++++++++++++
>>>>>>    2 files changed, 26 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi b/arch/arm/dts/k3-j721s2-binman.dtsi
>>>>>> index 73af184d27e..9c8b29f53bb 100644
>>>>>> --- a/arch/arm/dts/k3-j721s2-binman.dtsi
>>>>>> +++ b/arch/arm/dts/k3-j721s2-binman.dtsi
>>>>>> @@ -273,6 +273,14 @@
>>>>>>                        };
>>>>>>                    };
>>>>>> +#ifdef CONFIG_K3_HSM_FW
>>>>>> +                hsm {
>>>>>> +                    hsm: blob-ext {
>>>>>> +                        filename = "ti-hsm/hsm-demo-firmware-j721s2-hs.bin";
>>>>>> +                    };
>>>>>> +                };
>>>>>> +#endif
>>>>>> +
>>>>> Why do we have the hsm binaries pre-signed? Having a common binary like
>>>>> the DM with signing using ti-secure might be a better option.
>>>>
>>>> Andrew can correct me if I am wrong,
>>>> HSM is meant to run secure software stack and services like Authentication etc. It is a +1 to TIFS. To establish ROT, we need the HSM binary to be encrypted, and authenticated by TIFS first before it can do stuff by itself. DM is not a secure entity, so signing the image doesn't make sense for me.
>>>>
>>> I think Anshul is not suggesting that the HSM binary be unencrypted/unauthenticated.
>>> Rather that the encrypting/signing be done here in binman like we do with TF-A/OP-TEE.
>>> (which both are part trusted images to be loaded by TIFS).
>>>
>>> To that suggestion I agree, the customer will be doing the signing of this binary, right?
>>> If so then since all other customer signing is done as part of binman, it makes sense
>>> to also sign HSM firmware here too.
>>>
>>> Andrew
>> Yeah, that is what I was going for. With that change it could be
>> possible to also have a single binary for all platforms (gp, hs, hs-fs)
>> in ti-linux-firmware?
>>
>> Also, why are we not adding an unsigned variant of the hsm binary in
>> tispl.bin_unsigned?
> 
> 
> What's the use case for that? I think we established that HSM won't be used unsigned. So it will just bloat the FIT and never be used.
> 

We ship an unsigned HSM firmware for GP devices[0], and in patch [7/7] of this
series you add support for loading that unsigned HSM firmware. Seems odd to
then not ever package it here in binman and claim we will never use it?

Andrew

[0] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-hsm?h=ti-linux-firmware