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