Add a Rockchip secure boot PTA #7511
Conversation
|
Where do you implement the user of the PTA? Directly in the bootloader? |
I have patches for a user implemented as a barebox driver and command. These are not public yet, because I wanted some feedback on the API from an OP-TEE perspective, first. I think that implementing the user as a Linux user space application to enable secure boot from Linux would be useful as well. However, I am not familiar enough with OP-TEE to know if there are any limitations to that use case. |
|
This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time. |
tretter
force-pushed
the
rockchip-secure-boot
branch
from
878937a to
7a6baad
Compare
I can't figure out how to remove the stale label. The branch update didn't remove the label, either. Now I'm adding a comment to prevent the close due to inactivity. |
I suppose only admins can remove the label, which I have just done. It will appear again in 30 days. |
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 <[email protected]>
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 <[email protected]>
tretter
force-pushed
the
rockchip-secure-boot
branch
from
7a6baad to
047772c
Compare
|
Rebased on master, dropped drivers: rockchip: extract OTP driver from rk3588 platform and fixed merge conflicts. |
3 participants
This merge request adds a PTA for enabling secure boot on Rockchip SoCs.
On Rockchip SoCs, secure boot must be enabled from the secure world. There are other solutions to enable secure boot very early from a bootloader or special application. This has the drawback that user interaction or scripting on the device is not possible, which is inconvenient during development and software deployment in the factory.
This PTA allows enabling secure boot for Rockchip devices with an application running in the normal world.
There are still a few open issues in the PTA. I'd like to get some feedback on this approach:
Function wise, the PTA API provides 3 functions, which work as follows:
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.
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.
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.
After that, the ROM code on the device will only accept images that are signed with the RSA key that matches the hash that has been burned into the OTP area.