| Message ID | 1515768744-25246-1-git-send-email-bryan.odonoghue@linaro.org |
|---|---|
| Headers | show |
| Series | Add new OPTEE bootm support to u-boot | expand |
Hi Bryan, On Fri, Jan 12, 2018 at 02:52:15PM +0000, 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 image type is a >directly bootable image as described here : >http://mrvan.github.io/optee-imx6ul > >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. > >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 Thanks for patchset. I gave a test on i.MX7D-SDB and it works well. Tested-by: Peng Fan <peng.fan@nxp.com> > >-- >2.7.4 > >_______________________________________________ >U-Boot mailing list >U-Boot@lists.denx.de >https://lists.denx.de/listinfo/u-boot
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? > > 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 >
> 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. >> >> 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 >> > >
> 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
On Mon, Jan 15, 2018 at 11:29:41AM +0100, Dr. Philipp Tomsich wrote: > >> 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. Falcon-mode is a good feature, but not everyone use Falcon-mode. > >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). Providing the bootm way gives developer a choice for those that does not support SPL. We have been using bootm to boot optee for long time. Thanks, Peng > >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 > >_______________________________________________ >U-Boot mailing list >U-Boot@lists.denx.de >https://lists.denx.de/listinfo/u-boot
> On 15 Jan 2018, at 13:03, Peng Fan <van.freenix@gmail.com> wrote: > > On Mon, Jan 15, 2018 at 11:29:41AM +0100, Dr. Philipp Tomsich wrote: >> >>> 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. > > Falcon-mode is a good feature, but not everyone use Falcon-mode. > >> >> 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). > > > Providing the bootm way gives developer a choice for those that does not > support SPL. We have been using bootm to boot optee for long time. Interesting to hear. Could you provide some additional feedback on how you boot these boards today (e.g. how is U-Boot loaded, if there is no SPL; is U-Boot running in secure mode, as we seem to have inferred from the earlier conversation)? > > Thanks, > Peng > >> >> 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 >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de> >> https://lists.denx.de/listinfo/u-boot <https://lists.denx.de/listinfo/u-boot> > > --
On 15/01/18 12:03, Peng Fan wrote: > Providing the bootm way gives developer a choice for those that does not > support SPL. We have been using bootm to boot optee for long time. > > Thanks, > Peng Philipp, My understanding is that bootm is the preferred armv7 method.. In principle we should be able to support both the SPL and bootm methods.