On 15 Jan 2018, at 11:24, Dr. Philipp Tomsich philipp.tomsich@theobroma-systems.com wrote:
On 15 Jan 2018, at 05:39, Kever Yang kever.yang@rock-chips.com wrote:
Hi Bryan,
On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
This series adds a new OPTEE bootable image type to u-boot, which is directly bootable with the bootm command.
There is already a TEE image type but, in this case the TEE firmware is loaded into RAM, jumped into and then back out of.
This is how OP-TEE upstream designed flow, isn't it?
This image type is a directly bootable image as described here : http://mrvan.github.io/optee-imx6ul
Still not clear about the detail flow you are using :( I don't understand why we need to support OP-TEE in bootm. Do you make U-Boot working in secure word?
I would also prefer if we could leave the secure world prior to executing the full U-Boot… it reduces the attack surface and will be similar to what we do on ARMv8 with ATF.
I forgot to mention that Falcon-mode w/ OPTEE will only be possible if the OPTEE is loaded from SPL.
As I would like to avoid having two different ways to load an OPTEE within U-Boot, this seems to also bias the “default boot sequence” towards inserting OPTEE between SPL and the OS-stage (whether this is IH_OS_U_BOOT, IH_OS_LINUX or something else).
Regards, Philipp.
Instead of reusing the Linux bootable image type instead a new image type is defined, which allows us to perform additional image verification, prior to handing off control via bootm.
OPTEE images get linked to a specific address at compile time and must be loaded to this address too. This series extends out mkimage with a new image type that allows the OPTEE binary link location to be validated against CONFIG_OPTEE_TZDRAM_BASE and CONFIG_OPTEE_TZDRAM_SIZE respectively prior to proceeding through the bootm phase.
Once applied you can generate a bootable OPTEE image like this
mkimage -A arm -T optee -C none -d ./out/arm-plat-imx/core/tee.bin uTee.optee
That image can then be booted directly by bootm. bootm will verify the header contents of the OPTEE binary against the DRAM area carved out in u-boot. If the defined DRAM area does not match the link address specified we refuse to boot.
Kever - I'd like to suggest that your OPTEE SPL image takes a different image type IH_TYPE_OPTEE_SPL ? to indicate the different behavior your image type has versus a directly bootable bootm image.
Well, I think we can decide after everything is clear.
Thanks, -Kever
Bryan O'Donoghue (9): optee: Add lib entries for sharing OPTEE code across ports optee: Add CONFIG_OPTEE_TZDRAM_SIZE optee: Make OPTEE_TZDRAM_BASE a mandatory define optee: Add optee_image_get_entry_point() optee: Add optee_image_get_load_addr() tools: mkimage: add optee image type optee: Add optee_verify_bootm_image() optee: Improve error printout bootm: optee: Add mechanism to validate an OPTEE image before boot
common/bootm.c | 11 +++++++- common/image.c | 1 + include/image.h | 1 + include/tee/optee.h | 41 ++++++++++++++++++++++++++++++ lib/Kconfig | 1 + lib/Makefile | 1 + lib/optee/Kconfig | 16 ++++++++++++ lib/optee/Makefile | 7 ++++++ lib/optee/optee.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++ tools/default_image.c | 25 ++++++++++++++----- 10 files changed, 166 insertions(+), 7 deletions(-) create mode 100644 lib/optee/Kconfig create mode 100644 lib/optee/Makefile create mode 100644 lib/optee/optee.c