Repository navigation
arch/arm64/imx9: add an ELE-backed /dev/random driver - #20191
Conversation
d7ba53b to
0e7024c
Compare
…ual one. The ELE addresses memory physically; cache maintenance takes a virtual address. Both buffer calls supply one and use it for both, in opposite directions: get_random() runs up_flush_dcache() on a physical address, get_key() hands the enclave a virtual one. Both fail silently, and both are correct only while the two are equal. Take the virtual address in both, maintain the cache on it, and translate for the message. get_random() also gains the alignment check get_key() already has. Signed-off-by: Royyan Zahir <royzah@gmail.com>
|
Run on hardware: i.MX93 Cortex-A55, PX4 kernel build, NuttX 12.11.0. Shell over MAVLink Both reads distinct, Tested with this branch applied onto a downstream i.MX93 board tree: |
|
@acassis added the driver docs you asked for, on the i.MX9x page rather than the board page since it is a chip peripheral. Covers the Kconfig chain and the health checks, with the hardware log. @xiaoxiang781216 the Out of draft now, ready for another look. |
The i.MX9 has a true random number generator behind the EdgeLock Enclave and imx9_ele_get_random() to reach it, but nothing registers a character device for it, so the entropy pool is never seeded from hardware. stm32h7, nrf52, lpc54xx and rp23xx all provide one; imx9 does not. imx9_ele.c was built only for CONFIG_IMX9_BOOTLOADER, putting the enclave out of reach of the application core. It moves behind a new CONFIG_IMX9_ELE that the bootloader selects, so existing configurations build as before. A transfer that never lands is silent, so the buffer is prefilled with a pattern and a block still holding it is refused, as is an all-zero block and, by the FIPS 140-2 continuous test, a repeat of the one before. Compiles for imx93-evk:nsh with CONFIG_IMX9_RNG=y. Signed-off-by: Royyan Zahir <royzah@gmail.com>
The i.MX9x platform page carried only a board toctree, so there was nowhere describing what the chip supports. Add a peripheral table and a section on the random number generator: the Kconfig chain, which of DEV_RANDOM and DEV_URANDOM come on by themselves, and the health checks a block must pass before a read returns it. Signed-off-by: Royyan Zahir <royzah@gmail.com>
|
Hi @acassis |
|
@acassis gentle bump: the docs you asked for are in and xiaoxiang's approved. Anything else you'd like changed? |
Why
imx9_ele_get_random()exists, but nothing registers a device for it, so the i.MX9 entropy pool is never seeded from hardware.stm32h7,nrf52,lpc54xxandrp23xxall ship this driver;imx9does not.Modelled on https://github.com/apache/nuttx/blob/master/arch/arm/src/stm32h7/stm32_rng.c
How
imx9_ele.cbuilt only forCONFIG_IMX9_BOOTLOADERCONFIG_IMX9_ELEthat the bootloader selects, so existing configs are unchangedZero alone could not tell "the write never arrived" from "the ELE answered with zeros".
Depends on
#20196
Tested
Compiles for
imx93-evk:nshwithCONFIG_IMX9_RNG=y,tools/nxstyleclean.That build is what caught the first version gating
IMX9_ELEonIMX9_HAVE_MU, which onlyARCH_CHIP_IMX95selects, so the driver was unselectable on the chip it is for.