| 74eb4d9e | 23-Jan-2026 |
Quentin Schulz <quentin.schulz@cherry.de> |
plat-rockchip: px30: set CFG_CRYPTO_WITH_CE ?= y
Similarly to what's been done to RK3399 in commit 3ab148c8f4a0
("plat-rockchip: rk3399: set CFG_CRYPTO_WITH_CE ?= y"), we can enable
the Arm Cryptogr
plat-rockchip: px30: set CFG_CRYPTO_WITH_CE ?= y
Similarly to what's been done to RK3399 in commit 3ab148c8f4a0
("plat-rockchip: rk3399: set CFG_CRYPTO_WITH_CE ?= y"), we can enable
the Arm Cryptography Extensions by default for PX30 as Rockchip claims
they are supported in the datasheet[1].
Tested with:
xtest --aes-perf -m XTS -s 1000000 -n 1000
Before:
min=88574.2us max=91273us mean=88942.8us stddev=234.498us (cv 0.26365%) (10.7223MiB/s)
After:
min=3297.58us max=3655.75us mean=3464.66us stddev=59.7159us (cv 1.72357%) (275.258MiB/s)
Link: https://opensource.rock-chips.com/images/8/87/Rockchip_PX30_Datasheet_V1.4-20191227.pdf [1]
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
show more ...
|
| 2949576e | 06-Aug-2025 |
Michael Tretter <m.tretter@pengutronix.de> |
core: pta: add Rockchip secure boot PTA
The S_OTP area for the Rockchip secure boot RSA hash and status register
is accessible only from the secure world. Thus, secure boot must be
enabled from the
core: pta: add Rockchip secure boot PTA
The S_OTP area for the Rockchip secure boot RSA hash and status register
is accessible only from the secure world. Thus, secure boot must be
enabled from the secure world on these board.
The PTA implements 3 functions:
1. Ask the TA from the non-secure world about the current status and hash
of the hardware. This allows to inspect the current status of secure
boot on a specific device.
2. Write an RSA hash into the OTP fuses. It's the responsibility of the
user to calculate the hash and ensure that it matches the key, which
will be used to sign the images.
3. Actually lockdown the device by enabling secure boot. This is a
separate step to allow the user to verify the setup before
potentially bricking a device.
With these functions, a user may use a client running in the normal
world (for example in a boot loader or operating system) to enable
secure boot on a Rockchip device.
Implementing secure boot setup as an OP-TEE PTA has the advantage that
secure boot can be enabled at any time during the device setup instead
of during early boot. This allows a developer/user or additional scripts
to interact with the secure boot setup process.
The hash of the root key is accepted and reported as calculated by
sha256sum and internally converted to the correct byte order that needs
to be burned into the fuses.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| fabad06f | 07-Aug-2025 |
Michael Tretter <m.tretter@pengutronix.de> |
plat-rockchip: rk3588: define more OTP indexes
The OTP area contains other values in addition to the HW_UNIQUE_KEY. For
example, the SECURE_BOOT_STATUS and the RSA_HASH, which are used by the
ROM co
plat-rockchip: rk3588: define more OTP indexes
The OTP area contains other values in addition to the HW_UNIQUE_KEY. For
example, the SECURE_BOOT_STATUS and the RSA_HASH, which are used by the
ROM code to verify booted images, are located there as well.
Define the index (in 32 bit words) and length (in 32 bit words) of these
values, too, to allow applications to read and write these locations.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| 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 ...
|