[U-Boot] [PATCH v2 6/9] tools: mkimage: add optee image type

[Andrew F. Davis]

On 01/19/2018 05:59 PM, Bryan O'Donoghue wrote:
> 
> 
> On 19/01/18 20:14, Andrew F. Davis wrote:
>> On 01/19/2018 01:43 PM, Bryan O'Donoghue wrote:
>>> This patch adds support for bootable OPTEE images to mkimage. Currently
>>> there is a (Trusted Execution Environment) TEE image type, the TEE image
>>> type is installed to a memory location with u-boot continuing to own the
>>> boot process whereas the OPTEE image type defined here is a bootable
>>> image,
>>> which typically wants to live at a defined location in memory.
>>> Defining a
>>> new image type allows us to pull out the load address and entry point
>>> defined in the OPTEE header and having a separate image type lays the
>>> foundation for a subsequent patch to validate the OPTEE memory
>>> defined in a
>>> board-port matches the link location specified in the OPTEE bootable
>>> image.
>>>
>>> example usage:
>>>
> 
>>> uTee.optee
>>>
>>> making a separate image type means you don't need to specify things like
>>> entry point and load address as you would if you were defining the OPTEE
>>> image as a linux image.
>>>
>>
>> I'm still not getting the reasoning for this all, you can have the load
>> address checks and relocation stuff inside your loadable handler:
>>
>> U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process
> Hi Andrew,
> 
> As I understand it, that's a board-specific method, which wants to
> install a TEE (jump into a TEE and return to u-boot), whereas the aim
> with this patch-set is to chain-load and boot via TEE - OPTEE in this case.
> 

This is not board-specific, this is the flow all ARM boards I know of
use (except i.MX 6).

It is certainly possible to use the same flow on TI boards if we wanted,
we just don't as in my mind OP-TEE logically should jump back to the
non-secure side were it was called from so non-secure boot can continue.
Not act as another boot loader stage.

Is there some technical reason I am missing as to why you want to use
this alternate flow?

> I should make that clearer in the patch text description.
> 

That would be great.

> The example from Peng Fang
> 
>>> mkimage -A arm -O linux -C none -a 0x9c0fffe4 -e 0x9c100000 -d
>>> ./out/arm-plat-imx/core/tee.bin uTee
> 

I haven't used mkimage in a while, but how is this any different than
what we do with the kernel image? Why do we need to pull this info out
of the header when we don't do the same for Linux?

> is then simplified down to this
> 
>>> mkimage -A arm -T optee -C none -d ./out/arm-plat-imx/core/tee.bin
> > and remove the requirement to pass load and entry point on the command
> line.
> 

To me the save in this command (which should be handled automatically
during the build process), doesn't justify the additional complexity in
the boot flow.

> The boot-flow looks like this
> 
> BootROM -> u-boot {load kernel, dtb, optee} -> OPTEE -> Kernel
> 
> Whereas - as I understand it the flow on the TI examples you have is
> 
> BootROM -> u-boot {load kernel, dtb, TEE} -> TEE -> u-boot -> Kernel
> 


This is correct, we also on some platforms load additional firmware, so
returning to u-boot after each image is deployed is a must.

BootROM -> (u-boot  u-boot   u-boot  u-boot) -> kernel
             |      |  |     |   |      |
             v      |  v     |   v      |
             TEE ->    PMMC ->   Something else, etc..

You seem to be locking yourself in with your flow, as now TEE *must* be
the last item you load. What happens when you want to make secure calls
into OP-TEE from U-Boot? You won't be able to move it back in the
stages. (We are now doing this to handle some new Android secure-boot
requirements, so it is not that far-fetched)


> Note: I do believe IH_TYPE_TEE is the right type to use for Kever's
> patch with the SPL - because again as I understand it - the model is
> 
> BootROM -> SPL -> Install TEE -> u-boot -> etc
> 
> ---
> bod