| fd6196d4 | 02-Oct-2025 |
Michael Tretter <m.tretter@pengutronix.de> |
plat-rockchip: rk3588: reject all zero HUK
If the generated HUK consists of all zeros, it cannot be distinguished
from a missing HUK in the OTP. If such a HUK is burned into the OTP, the
next read w
plat-rockchip: rk3588: reject all zero HUK
If the generated HUK consists of all zeros, it cannot be distinguished
from a missing HUK in the OTP. If such a HUK is burned into the OTP, the
next read will return that no HUK was present and generate a new key.
The previous all-zero HUK may already have been used, which violates the
assumption that a HUK doesn't change.
Since a HUK that consists of all zeros is likely an error in the TRNG,
reject the generated HUK, report an error and let upper layers handle
the error.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
show more ...
|
| 951488c0 | 27-Aug-2025 |
Michael Tretter <m.tretter@pengutronix.de> |
plat-rockchip: rk3588: cache HUK in memory
I observed timeout errors when OP-TEE reads the HUK from the OTP area
while running the optee-xtests (tests 1006 and 4013) or using the
pkcs#11 TA.
This i
plat-rockchip: rk3588: cache HUK in memory
I observed timeout errors when OP-TEE reads the HUK from the OTP area
while running the optee-xtests (tests 1006 and 4013) or using the
pkcs#11 TA.
This issue is circumvented by reading the HUK once and caching it in
memory for later use. As a side-effect, this reduces the accesses/reads
from the OTP area.
Unfortunately, I don't know the root cause for the timeout while reading
the fuses. I guess that there is a disabled clock which prevents the
read, but I didn't look further, since caching works fine.
While the documentation recommends to never process the HUK in software,
it is read and processed anyway if it can be read from the fuses. Thus,
I don't think that caching has an effect on the security of the HUK.
The caching is inspired by the HUK handling implemented in the nvmem
driver.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
show more ...
|
| 46b94a62 | 26-Aug-2025 |
Michael Tretter <m.tretter@pengutronix.de> |
plat-rockchip: rk3588: refactor reading of HUK
Split the function that reads, generates and persists the HUK into
several helper functions to make the code more readable and simplify
error handling.
plat-rockchip: rk3588: refactor reading of HUK
Split the function that reads, generates and persists the HUK into
several helper functions to make the code more readable and simplify
error handling.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@foss.st.com>
show more ...
|
| 6169a1f6 | 04-Feb-2025 |
Chris Morgan <macromorgan@hotmail.com> |
plat-rockchip: rk3588: Correct TZDRAM_START and SHMEM_START
Update the TZDRAM_START and SHMEM_START values to match the PX30 and
RK3399 values. If this is not done, a compressed kernel using the
def
plat-rockchip: rk3588: Correct TZDRAM_START and SHMEM_START
Update the TZDRAM_START and SHMEM_START values to match the PX30 and
RK3399 values. If this is not done, a compressed kernel using the
default value of kernel_comp_addr_r (0x0a000000) within U-Boot and
having a decompressed size greater than 28MiB puts the decompressed
kernel in the reserved address space for OP-TEE that starts at
0x08400000. Using the values for the RK3399 and PX30 avoids this
problem.
Fixes: 14754b93b1b7 ("plat-rockchip: add support for Rockchip rk3588")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
show more ...
|
| 12a5f037 | 06-Nov-2024 |
Ahmad Fatoum <ahmad@a3f.at> |
plat-rockchip: allow specifying DRAM via CFG options
It's currently not possible to use CFG_CORE_DYN_SHM with the Rockchip
platforms, because OP-TEE doesn't know what non-secure memory is
available;
plat-rockchip: allow specifying DRAM via CFG options
It's currently not possible to use CFG_CORE_DYN_SHM with the Rockchip
platforms, because OP-TEE doesn't know what non-secure memory is
available; Device tree is not used and no DDR ranges are registered.
This precludes interacting with OP-TEE from barebox and U-Boot, which
currently only implement OP-TEE communication with dynamic shared
memory.
Make it possible to use CFG_CORE_DYN_SHM=y by adding two sets of config
variables to register memory:
CFG_DRAM_BASE, CFG_DRAM_SIZE:
For the main memory in the first 4G up to the MMIO range beyond
the end of the first RAM bank
CFG_NSEC_DDR_1_BASE, CFG_NSEC_DDR_1_SIZE:
For the remainder of the main memory above the MMIO regions.
OP-TEE will take care to carve out the secure memory ranges.
This has been tested on an RK3399 with barebox using OP-TEE's HWRNG TA.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
show more ...
|