diff mbox series

[v3,9/9] ARM: dts: stm32: add RNG node for STM32MP13x platforms

Message ID 20230921080301.253563-10-gatien.chevallier@foss.st.com (mailing list archive)
State Accepted
Delegated to: Herbert Xu
Headers show
Series hwrng: stm32: support STM32MP13x platforms | expand

Commit Message

Gatien CHEVALLIER Sept. 21, 2023, 8:03 a.m. UTC
The RNG on STM32MP13 offers upgrades like customization of its
configuration and the conditional reset.

The hardware RNG should be managed in the secure world for but it
is supported on Linux. Therefore, is it not default enabled.

Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp131.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Kamlesh Gurudasani Sept. 22, 2023, 8:20 a.m. UTC | #1
Gatien Chevallier <gatien.chevallier@foss.st.com> writes:

> The RNG on STM32MP13 offers upgrades like customization of its
> configuration and the conditional reset.
>
> The hardware RNG should be managed in the secure world for but it
> is supported on Linux. Therefore, is it not default enabled.
Just curious, will there be concurrent access? If yes, how do you manage
the entropy in that case?

If you allow access to RNG from normal world, can attacker change the
setting to generate more predicatable numbers leading this to secure
world as well.

I understand that you're leaving the enablement part to customer but
you still have to allow RNG access to normal world for that.

-Kamlesh
Gatien CHEVALLIER Sept. 25, 2023, 9:31 a.m. UTC | #2
Hi Kamlesh,

On 9/22/23 10:20, Kamlesh Gurudasani wrote:
> Gatien Chevallier <gatien.chevallier@foss.st.com> writes:
> 
>> The RNG on STM32MP13 offers upgrades like customization of its
>> configuration and the conditional reset.
>>
>> The hardware RNG should be managed in the secure world for but it
>> is supported on Linux. Therefore, is it not default enabled.
> Just curious, will there be concurrent access? If yes, how do you manage
> the entropy in that case?
> 

Any read on the data register leads to its refreshment. There can be
only one access at a time at the bus level. The rest (FIFO is empty
after request, etc...) is managed by the code in this patchset.

> If you allow access to RNG from normal world, can attacker change the
> setting to generate more predicatable numbers leading this to secure
> world as well.
> 
> I understand that you're leaving the enablement part to customer but
> you still have to allow RNG access to normal world for that.
> 
> -Kamlesh

If RNG is secure, then it should be managed by the secure world and
accessed via some interface. Ours is OP-TEE RNG PTA. The secure level
of the peripheral is managed by the ETZPC, which manages the security
configuration of the board's peripherals.

If the RNG is assigned to the non-secure world, then yes, the non-secure
world can access the RNG configuration. Now, your question is: what
happens to the secure world in such case? The answer is that it should
run on a pseudo-random software RNG seeded at boot by the hardware RNG.
So there's no link anymore if non-secure world deteriorates the
hardware RNG configuration.

Of course, if such choice is made, it's up to the customer to see the
whole picture.

Best regards,
Gatien
diff mbox series

Patch

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index ac90fcbf0c09..39db82b782eb 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -1220,6 +1220,14 @@  mdma: dma-controller@58000000 {
 			dma-requests = <48>;
 		};
 
+		rng: rng@54004000 {
+			compatible = "st,stm32mp13-rng";
+			reg = <0x54004000 0x400>;
+			clocks = <&rcc RNG1_K>;
+			resets = <&rcc RNG1_R>;
+			status = "disabled";
+		};
+
 		fmc: memory-controller@58002000 {
 			compatible = "st,stm32mp1-fmc2-ebi";
 			reg = <0x58002000 0x1000>;