linux-kernel - Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <acd087a1-c10d-43dd-8900-d05591b0c4b0@ti.com>
Date: Thu, 10 Apr 2025 18:50:22 +0530
From: "Kumar, Udit" <u-kumar1@...com>
To: Michael Walle <mwalle@...nel.org>, Manorit Chawdhry <m-chawdhry@...com>
CC: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
        Tero
 Kristo <kristo@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof
 Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: dts: ti: k3-am62p-j722s: add rng node

Hi Michael,

On 4/10/2025 4:56 PM, Michael Walle wrote:
> Hi Manorit,
>
>>>>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
>>>>>>>>> [..]
>>>>>>>> For completeness , this is ok to add this node but
>>>>>>>> should be kept disabled
>>>>>>> Shouldn't it be "reserved" then, see [1].
>>>>>> yes, should be reserved.
>>>>>>
>>>>>> With marking status as reserved.
>>>>>>
>>>>>> Please use Reviewed-by: Udit Kumar <u-kumar1@...com>
>>>>> Thanks.
>>>>>
>>>>>>>> similar to
>>>>>>>>
>>>>>>>> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi#L662
>>>>>>> j784s4, j721e and j721s2 have them enabled. What is the rule here?
>>>>>> J784s4, j721e and j721s2 SOCs has two TRNG blocks,
>>>>>>
>>>>>> example for j721e, one is used by kernel [0] and another by
>>>>>> optee [1].
>>>>>>
>>>>>>
>>>>>>> You also disable the hwrng in optee in your evm according to [2]:
>>>>>>> CFG_WITH_SOFTWARE_PRNG=y
>>>>>> We are planning to use this hardware block by secure firmware.
>>>>>>
>>>>>> Therefore request not to use by optee as well
>>>>> How will you be able to access the RNG from linux and u-boot? I'm
>>>>> asking because I'll need it in u-boot for the lwip stack and the
>>>>> HTTPS protocol.
>>>> For now,  If you need TRNG then I can suggest to use optee TRNG (ie
>>>> build
>>>> optee with HW TRNG).
>>> I'll be using an uboot TRNG driver. But how will that work in
>>> the future if the RNG is used by the secure firmware?
>> Wondering if this would be of interest to you [0]. I think since this
>> device only has one TRNG, there has to be a master around and we can
>> mitigate that from OP-TEE as of now, incase anything changes in future
>> then the communication channel between OP-TEE and the secure firmware
>> can be established but currently it's still at work. I think the best
>> way to go forward is to get the numbers from OP-TEE atm IMHO.
> I saw the optee rng. But as of now, the instructions are to use a
> software PRNG for optee. Thus, if someone compiles optee by
> following the instructions, it's unlikely to work.
>
> Would TI willing to agree to change the building docs and enable the
> TRNG in optee and then work on moving the TRNG into the secure
> firmware and build a channel between optee and that firmware? Right
> now, the TRNG seems pretty useless as we cannot use it neither from
> u-boot or linux (and being future proof).

Thanks for note,

I agree to update doc two times

1) with current state ie use optee based trng

2) When fw based trng is available,


>
> -michael