[U-Boot] [PATCH 0/9] Add new OPTEE bootm support to u-boot

[Dr. Philipp Tomsich]

> On 15 Jan 2018, at 11:24, Dr. Philipp Tomsich <philipp.tomsich at theobroma-systems.com> wrote:
> 
>> 
>> On 15 Jan 2018, at 05:39, Kever Yang <kever.yang at 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