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

[Beleswar Prasad Padhi <b-padhi@ti.com>]

Hi Andrew,

On 08/05/25 20:58, Andrew Davis wrote:
> 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@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. 


That is a System Firmware limitation; i.e., no support of loading HSM FW for GP devices. We are providing a workaround for that by manually loading it from MCU R5 core. Besides, HSM SRAM should not even be accessible by MCU R5F core in the first place. HSM should only be accessible & loaded by TIFS. So once the SRAM is firewalled, this flow for loading GP bins won't work, and SYSFW will somehow have to support that, or we just give up unsigned bin load support.

> Seems odd to
> then not ever package it here in binman and claim we will never use it?


IMHO, users can "choose" to package that unsigned HSM bin and boot it in the current flow. Please let me know, if you are okay with packaging an unsigned HSM binary "by default", given the above caveat?

Thanks,
Beleswar

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