Using TRNG without Op-Tee fails during init

[dsanzecler]

I am trying to make the MA35D1's TRNG module work without op-tee. According to Nuvoton's documentation, this should be possible. Here is what I am doing:

1. In the TF-A, in the device tree, I set the TRNG as accessible from the non-secure environment:

   <TRNG_TZNS>,

2. In the Linux kernel, in my own device tree, I override the "optee_nuvoton" property of ma35d1.dtsi as "no", as the documentation suggests:

&trng { optee_nuvoton = "no"; status = "okay"; };

3. In the defconfig for the kernel, I enable the HW_RANDOM_MA35D1 option and disable the optee support for hw_random:

CONFIG_HW_RANDOM_MA35D1=y
# CONFIG_HW_RANDOM_OPTEE is not set

After rebuilding everything (TF-A & kernel included), I can see that the driver found in drivers/char/hw_random/ma35d1-trng.c is included in the linux kernel, but it fails during initialization. What I could see is that inside ma35d1_trng_init() calls ma35d1_trng_gen_noise(), and, inside this function, the following function call is performed:

err = ma35d1_trng_issue_command(tdev, TCMD_GEN_NOISE);

Inside the ma35d1_trng_issue_command() function, after writing the command to the CTRL register, it repeatedly checks that the ISTAT_DONE flag is activated on the ISTAT register, but this never happens so EBUSY is returned.

The result is that, during the kernel init process, after a 2 second timeout, the following message is printed:

nuvoton-trng: probe of 40b90000.trng failed with error -16

I have tried to get information about these registers but the TRNG is not documented in the MA35D1 Reference Manual (I guess this is done on purpose for security reasons). So can't know why the ISTAT register is not returning the expected value. I guess this must be a bug in the driver, something must not be done properly. Can you clarify what's going on?

[dsanzecler]

I also read the 'MA35D1 TSI User Manual', and it suggests that the TRNG is located inside an independent subsystem, the TSI (Trusted Secure Island), and that this is only accessible by fetching commands from a secure (TZS) environment. So, not from Linux.

But this seems to contradict other documentation. Which one is it? Is the TRNG accessible from Linux?

[ychuang3]

If TSI is enabled, the Crypto Accelerator, TRNG, and Key Store are all integrated within the TSI. In this scenario, the only way to utilize these IPs is through the TSI command interface. Furthermore, the TSI interface operates exclusively in secure mode. Therefore, TSI cannot be accessed from Linux, which always runs in non-secure mode. This is why we require OP-TEE, the secure operating system.

If TSI is not enabled, the Crypto Accelerator, TRNG, and Key Store can be directly accessed via the register interface and can function in non-secure mode. In such cases, Linux drivers can support these IPs without the need for OP-TEE.

Currently, all the published MA35D1 series parts support TSI. Non-TSI series may be introduced in 2024 Q1 or Q2.

[dsanzecler]

But in the document 'NuMicro Family MA35D1 Linux User Manual', in the section '3.9.2 - TRNG', when it says that TRNG can be configured with 'optee_nuvoton="no"', what it really means is that it will be supported in the future?

Currently, is there any way to use the TRNG (or the PRNG) from linux without using OP-TEE?

[ychuang3]

optee_nuvoton="no" is for non-TSI chips only, which were not published at present.
The driver supports both TSi and non-TSI chips, and document it in the user manual.

[dsanzecler]

so, right now, for chips with TSI such as the MA35D1, is there any way to use the TRNG (or the PRNG) from linux without using OP-TEE?

[ychuang3]

No, OP-TEE is must.

[dsanzecler]

Ok, thanks for the clarification.

Before, you said: "Currently, all the published MA35D1 series parts support TSI. Non-TSI series may be introduced in 2024 Q1 or Q2."

Does this mean that in 2024 Q1 or Q2 you will release a version of MA35D1 with no TSI? Will TRNG and PRNG be accessible from Linux in those versions?

[ychuang3]

Yes, but it will be MA35H0/D0 with CPU running at 650 MHz, not MA35D1.

[dsanzecler]

Ok thanks.

To be clear, I think the document "NuMicro Family MA35D1 Linux User Manual" is not correct, because it says that TRNG can be configured as <TRNG_TZNS> in TF-A and as "optee_nuvoton" = no in Linux. And you are telling me this is not true, and will never be true for MA35D1.

This led me to build a system with no OP-TEE, and now I have to go back and include OP-TEE in my system again, otherwise I can't use the TRNG...