[PATCH 0/4] improving OP-TEE support for u-boot-based platforms

[PATCH 0/4] improving OP-TEE support for u-boot-based platforms

[Yann Dirson]

From: Yann Dirson <yann@blade-group.com>

While working on integrating OP-TEE on rk3399 with a readonly rootfs,
I figured that a couple of things would be good to have in the optee
recipes.

Also, having started to work on old meta-linaro/meta-optee initially:
 - I had to duplicate some of the work done here and had submitted a
   similar patch upstream
 - pycrypto simplification became obvious

Yann Dirson (4):
  arm/optee: use pycryptodome rather pycryptodomex
  arm/optee-os: mark LDFLAGS patch as submitted
  arm/optee-os: deploy tee.elf for u-boot
  arm/optee-client: create the /data/tee/ directory needed by
    tee-supplicant

 meta-arm/recipes-security/optee/optee-client.inc            | 6 ++++++
 meta-arm/recipes-security/optee/optee-examples.inc          | 2 +-
 .../optee-examples/0001-make-Pass-ldflags-during-link.patch | 2 +-
 meta-arm/recipes-security/optee/optee-os.inc                | 4 ++--
 meta-arm/recipes-security/optee/optee-test.inc              | 2 +-
 5 files changed, 11 insertions(+), 5 deletions(-)

-- 
2.30.2

[PATCH 1/4] arm/optee: use pycryptodome rather pycryptodomex

[Yann Dirson]

From: Yann Dirson <yann@blade-group.com>

Recent versions of OP-TEE perfectly build with pycryptodome, no need for
the pycryptodomex transition package any more.

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
 meta-arm/recipes-security/optee/optee-examples.inc | 2 +-
 meta-arm/recipes-security/optee/optee-os.inc       | 2 +-
 meta-arm/recipes-security/optee/optee-test.inc     | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-arm/recipes-security/optee/optee-examples.inc b/meta-arm/recipes-security/optee/optee-examples.inc
index 851043b..81c31bc 100644
--- a/meta-arm/recipes-security/optee/optee-examples.inc
+++ b/meta-arm/recipes-security/optee/optee-examples.inc
@@ -5,7 +5,7 @@ HOMEPAGE = "https://github.com/linaro-swg/optee_examples"
 LICENSE = "BSD-2-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=cd95ab417e23b94f381dafc453d70c30"
 
-DEPENDS = "optee-client optee-os python3-pycryptodomex-native"
+DEPENDS = "optee-client optee-os python3-pycryptodome-native"
 
 inherit python3native
 
diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
index f8697cf..34f586a 100644
--- a/meta-arm/recipes-security/optee/optee-os.inc
+++ b/meta-arm/recipes-security/optee/optee-os.inc
@@ -10,7 +10,7 @@ require optee.inc
 
 CVE_PRODUCT = "linaro:op-tee op-tee:op-tee_os"
 
-DEPENDS = "python3-pycryptodome-native python3-pycryptodomex-native python3-pyelftools-native"
+DEPENDS = "python3-pycryptodome-native python3-pyelftools-native"
 
 DEPENDS_append_toolchain-clang = " compiler-rt"
 
diff --git a/meta-arm/recipes-security/optee/optee-test.inc b/meta-arm/recipes-security/optee/optee-test.inc
index 877bdeb..f09b9d2 100644
--- a/meta-arm/recipes-security/optee/optee-test.inc
+++ b/meta-arm/recipes-security/optee/optee-test.inc
@@ -13,7 +13,7 @@ require optee.inc
 # When upgraded we should be able to remove this limitation
 COMPATIBLE_HOST_libc-musl = 'null'
 
-DEPENDS = "optee-client optee-os python3-pycryptodomex-native"
+DEPENDS = "optee-client optee-os python3-pycryptodome-native"
 
 SRC_URI = "git://github.com/OP-TEE/optee_test.git \
            file://0001-host-xtest-Adjust-order-of-including-compiler.h.patch \
-- 
2.30.2

[PATCH 2/4] arm/optee-os: mark LDFLAGS patch as submitted

[Yann Dirson]

From: Yann Dirson <yann@blade-group.com>

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
 .../optee-examples/0001-make-Pass-ldflags-during-link.patch     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-arm/recipes-security/optee/optee-examples/0001-make-Pass-ldflags-during-link.patch b/meta-arm/recipes-security/optee/optee-examples/0001-make-Pass-ldflags-during-link.patch
index 0894a7a..84202ef 100644
--- a/meta-arm/recipes-security/optee/optee-examples/0001-make-Pass-ldflags-during-link.patch
+++ b/meta-arm/recipes-security/optee/optee-examples/0001-make-Pass-ldflags-during-link.patch
@@ -8,7 +8,7 @@ for gnu_hash among others which sets the linking straight
 using LDFLAGS varible here means, we can affect the linker flags
 from build environment
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://github.com/linaro-swg/optee_examples/pull/85]
 
 Signed-off-by: Khem Raj <raj.khem@gmail.com>
 ---
-- 
2.30.2

[PATCH 3/4] arm/optee-os: deploy tee.elf for u-boot

[Yann Dirson]

From: Yann Dirson <yann@blade-group.com>

Integration of OP-TEE in the u-boot image is done with `TEE=tee.elf`.
This can now be done in a BSP layer with something like this in
`u-boot_%.bbappend`:

 OPTEE_DEPENDS ??= ""
 OPTEE_DEPENDS_rk3399 = " optee-os:do_deploy"

 do_compile[depends] .= "${OPTEE_DEPENDS}"

 do_compile_prepend_rk3399() {
     export TEE=${DEPLOY_DIR_IMAGE}/optee/tee.elf
 }

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
 meta-arm/recipes-security/optee/optee-os.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
index 34f586a..db8428a 100644
--- a/meta-arm/recipes-security/optee/optee-os.inc
+++ b/meta-arm/recipes-security/optee/optee-os.inc
@@ -58,7 +58,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 do_deploy() {
     install -d ${DEPLOYDIR}/optee
-    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${DEPLOYDIR}/optee/
+    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${B}/core/tee.elf ${DEPLOYDIR}/optee/
 }
 
 addtask deploy before do_build after do_install
-- 
2.30.2

[PATCH 4/4] arm/optee-client: create the /data/tee/ directory needed by tee-supplicant

[Yann Dirson]

From: Yann Dirson <yann@blade-group.com>

With a writable rootfs, tee-supplicant will create this directory as needed,
but on a readonly rootfs it's obviously not possible.

Getting a readonly-rootfs use-case fully working still require a proper writable
filesystem to be mounted there, but how to do that is distro policy, and correct
OP-TEE can be at least be checked by mounting a tmpfs there.

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
 meta-arm/recipes-security/optee/optee-client.inc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meta-arm/recipes-security/optee/optee-client.inc b/meta-arm/recipes-security/optee/optee-client.inc
index f697386..0198433 100644
--- a/meta-arm/recipes-security/optee/optee-client.inc
+++ b/meta-arm/recipes-security/optee/optee-client.inc
@@ -24,6 +24,8 @@ do_install_append() {
     install -D -p -m0644 ${WORKDIR}/tee-supplicant.service ${D}${systemd_system_unitdir}/tee-supplicant.service
     install -D -p -m0755 ${WORKDIR}/tee-supplicant.sh ${D}${sysconfdir}/init.d/tee-supplicant
 
+    install -d -m755 ${D}/data/tee
+
     sed -i -e s:@sysconfdir@:${sysconfdir}:g \
            -e s:@sbindir@:${sbindir}:g \
               ${D}${systemd_system_unitdir}/tee-supplicant.service \
@@ -35,3 +37,7 @@ SYSTEMD_SERVICE_${PN} = "tee-supplicant.service"
 INITSCRIPT_PACKAGES = "${PN}"
 INITSCRIPT_NAME_${PN} = "tee-supplicant"
 INITSCRIPT_PARAMS_${PN} = "start 10 1 2 3 4 5 . stop 90 0 6 ."
+
+FILES_${PN} += "\
+    /data/tee/ \
+"
-- 
2.30.2

Re: [meta-arm] [PATCH 1/4] arm/optee: use pycryptodome rather pycryptodomex

[Denys Dmytriyenko]

On Tue, Apr 13, 2021 at 11:40:35AM +0200, Yann Dirson wrote:
> From: Yann Dirson <yann@blade-group.com>
> 
> Recent versions of OP-TEE perfectly build with pycryptodome, no need for
> the pycryptodomex transition package any more.
> 
> Signed-off-by: Yann Dirson <yann@blade-group.com>

Reviewed-by: Denys Dmytriyenko <denis@denix.org>


> ---
>  meta-arm/recipes-security/optee/optee-examples.inc | 2 +-
>  meta-arm/recipes-security/optee/optee-os.inc       | 2 +-
>  meta-arm/recipes-security/optee/optee-test.inc     | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta-arm/recipes-security/optee/optee-examples.inc b/meta-arm/recipes-security/optee/optee-examples.inc
> index 851043b..81c31bc 100644
> --- a/meta-arm/recipes-security/optee/optee-examples.inc
> +++ b/meta-arm/recipes-security/optee/optee-examples.inc
> @@ -5,7 +5,7 @@ HOMEPAGE = "https://github.com/linaro-swg/optee_examples"
>  LICENSE = "BSD-2-Clause"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=cd95ab417e23b94f381dafc453d70c30"
>  
> -DEPENDS = "optee-client optee-os python3-pycryptodomex-native"
> +DEPENDS = "optee-client optee-os python3-pycryptodome-native"
>  
>  inherit python3native
>  
> diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
> index f8697cf..34f586a 100644
> --- a/meta-arm/recipes-security/optee/optee-os.inc
> +++ b/meta-arm/recipes-security/optee/optee-os.inc
> @@ -10,7 +10,7 @@ require optee.inc
>  
>  CVE_PRODUCT = "linaro:op-tee op-tee:op-tee_os"
>  
> -DEPENDS = "python3-pycryptodome-native python3-pycryptodomex-native python3-pyelftools-native"
> +DEPENDS = "python3-pycryptodome-native python3-pyelftools-native"
>  
>  DEPENDS_append_toolchain-clang = " compiler-rt"
>  
> diff --git a/meta-arm/recipes-security/optee/optee-test.inc b/meta-arm/recipes-security/optee/optee-test.inc
> index 877bdeb..f09b9d2 100644
> --- a/meta-arm/recipes-security/optee/optee-test.inc
> +++ b/meta-arm/recipes-security/optee/optee-test.inc
> @@ -13,7 +13,7 @@ require optee.inc
>  # When upgraded we should be able to remove this limitation
>  COMPATIBLE_HOST_libc-musl = 'null'
>  
> -DEPENDS = "optee-client optee-os python3-pycryptodomex-native"
> +DEPENDS = "optee-client optee-os python3-pycryptodome-native"
>  
>  SRC_URI = "git://github.com/OP-TEE/optee_test.git \
>             file://0001-host-xtest-Adjust-order-of-including-compiler.h.patch \
> -- 
> 2.30.2
> 

> 
> 
> 


-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [meta-arm] [PATCH 3/4] arm/optee-os: deploy tee.elf for u-boot

[Denys Dmytriyenko]

On Tue, Apr 13, 2021 at 11:40:37AM +0200, Yann Dirson wrote:
> From: Yann Dirson <yann@blade-group.com>
> 
> Integration of OP-TEE in the u-boot image is done with `TEE=tee.elf`.
> This can now be done in a BSP layer with something like this in
> `u-boot_%.bbappend`:

Well, this is not very standardized and is platform-specific.

For example, TI K3 platforms take tee-pager_v2.bin file into U-boot, not 
tee.elf one. But tee.elf still gets deployed for debugging purposes...

E.g. in meta-ti u-boot_%.bbappend:

PACKAGECONFIG[optee] = "TEE=${STAGING_DIR_HOST}${nonarch_base_libdir}/firmware/tee-pager_v2.bin,,optee-os"
PACKAGECONFIG_append_k3 = " optee"


>  OPTEE_DEPENDS ??= ""
>  OPTEE_DEPENDS_rk3399 = " optee-os:do_deploy"
> 
>  do_compile[depends] .= "${OPTEE_DEPENDS}"
> 
>  do_compile_prepend_rk3399() {
>      export TEE=${DEPLOY_DIR_IMAGE}/optee/tee.elf
>  }

To mee, the above PACKAGECONFIG approach is a bit cleaner...

In summary, I support availability of tee.elf, but besides do_deploy(), I 
would also suggest adding it to do_install()


> Signed-off-by: Yann Dirson <yann@blade-group.com>
> ---
>  meta-arm/recipes-security/optee/optee-os.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
> index 34f586a..db8428a 100644
> --- a/meta-arm/recipes-security/optee/optee-os.inc
> +++ b/meta-arm/recipes-security/optee/optee-os.inc
> @@ -58,7 +58,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
>  
>  do_deploy() {
>      install -d ${DEPLOYDIR}/optee
> -    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${DEPLOYDIR}/optee/
> +    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${B}/core/tee.elf ${DEPLOYDIR}/optee/
>  }
>  
>  addtask deploy before do_build after do_install
> -- 
> 2.30.2
> 

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [meta-arm] [PATCH 4/4] arm/optee-client: create the /data/tee/ directory needed by tee-supplicant

[Ricardo Salveti]

On Tue, Apr 13, 2021 at 6:41 AM Yann Dirson <yann.dirson@blade-group.com> wrote:
>
> From: Yann Dirson <yann@blade-group.com>
>
> With a writable rootfs, tee-supplicant will create this directory as needed,
> but on a readonly rootfs it's obviously not possible.
>
> Getting a readonly-rootfs use-case fully working still require a proper writable
> filesystem to be mounted there, but how to do that is distro policy, and correct
> OP-TEE can be at least be checked by mounting a tmpfs there.

It might be better here to follow FHS and use a standard directory for
the writable content (e.g. /var) instead. This should cover most
distro configuration.

> Signed-off-by: Yann Dirson <yann@blade-group.com>
> ---
>  meta-arm/recipes-security/optee/optee-client.inc | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/meta-arm/recipes-security/optee/optee-client.inc b/meta-arm/recipes-security/optee/optee-client.inc
> index f697386..0198433 100644
> --- a/meta-arm/recipes-security/optee/optee-client.inc
> +++ b/meta-arm/recipes-security/optee/optee-client.inc
> @@ -24,6 +24,8 @@ do_install_append() {
>      install -D -p -m0644 ${WORKDIR}/tee-supplicant.service ${D}${systemd_system_unitdir}/tee-supplicant.service
>      install -D -p -m0755 ${WORKDIR}/tee-supplicant.sh ${D}${sysconfdir}/init.d/tee-supplicant
>
> +    install -d -m755 ${D}/data/tee
> +

You could give 'CFG_TEE_FS_PARENT_PATH=${localstatedir}/tee' to
EXTRA_OEMAKE, for example.

Cheers,
-- 
Ricardo Salveti

Re: [meta-arm] [PATCH 3/4] arm/optee-os: deploy tee.elf for u-boot

[Yann Dirson]

Hi Denis,

Le mar. 13 avr. 2021 à 22:56, Denys Dmytriyenko <denis@denix.org> a écrit :
>
> On Tue, Apr 13, 2021 at 11:40:37AM +0200, Yann Dirson wrote:
> > From: Yann Dirson <yann@blade-group.com>
> >
> > Integration of OP-TEE in the u-boot image is done with `TEE=tee.elf`.
> > This can now be done in a BSP layer with something like this in
> > `u-boot_%.bbappend`:
>
> Well, this is not very standardized and is platform-specific.
>
> For example, TI K3 platforms take tee-pager_v2.bin file into U-boot, not
> tee.elf one. But tee.elf still gets deployed for debugging purposes...
>
> E.g. in meta-ti u-boot_%.bbappend:
>
> PACKAGECONFIG[optee] = "TEE=${STAGING_DIR_HOST}${nonarch_base_libdir}/firmware/tee-pager_v2.bin,,optee-os"
> PACKAGECONFIG_append_k3 = " optee"
>
>
> >  OPTEE_DEPENDS ??= ""
> >  OPTEE_DEPENDS_rk3399 = " optee-os:do_deploy"
> >
> >  do_compile[depends] .= "${OPTEE_DEPENDS}"
> >
> >  do_compile_prepend_rk3399() {
> >      export TEE=${DEPLOY_DIR_IMAGE}/optee/tee.elf
> >  }
>
> To mee, the above PACKAGECONFIG approach is a bit cleaner...

Well, I did not like it either and went with a DISTRO_FEATURES approach,
see my meta-rockchip patches on yocto ml.  It would be nice if it was generic
enough, but your example above shows it probably needs some more
refining anyway.

Eg. even the PACKAGECONFIG you show above is still BSP-specific.
Maybe we could centralize in meta-arm the different ways to integrate
op-tee, and get the BSP to choose one ?

>
> In summary, I support availability of tee.elf, but besides do_deploy(), I
> would also suggest adding it to do_install()

I must say I was puzzled by those optee files put it a package for installation
in the target rootfs (but then as you say there seem to be many ways
to integrate
op-tee on different platforms).  If they're just useful for debugging,
they would look like
good candidates for a -dbg package: what use-case does the current optee-os
binary package serve ?

>
>
> > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > ---
> >  meta-arm/recipes-security/optee/optee-os.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
> > index 34f586a..db8428a 100644
> > --- a/meta-arm/recipes-security/optee/optee-os.inc
> > +++ b/meta-arm/recipes-security/optee/optee-os.inc
> > @@ -58,7 +58,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> >  do_deploy() {
> >      install -d ${DEPLOYDIR}/optee
> > -    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${DEPLOYDIR}/optee/
> > +    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${B}/core/tee.elf ${DEPLOYDIR}/optee/
> >  }
> >
> >  addtask deploy before do_build after do_install
> > --
> > 2.30.2
> >
>
> --
> Regards,
> Denys Dmytriyenko <denis@denix.org>
> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
> Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

Re: [meta-arm] [PATCH 4/4] arm/optee-client: create the /data/tee/ directory needed by tee-supplicant

[Yann Dirson]

Le mer. 14 avr. 2021 à 00:10, Ricardo Salveti <ricardo@foundries.io> a écrit :
>
> On Tue, Apr 13, 2021 at 6:41 AM Yann Dirson <yann.dirson@blade-group.com> wrote:
> >
> > From: Yann Dirson <yann@blade-group.com>
> >
> > With a writable rootfs, tee-supplicant will create this directory as needed,
> > but on a readonly rootfs it's obviously not possible.
> >
> > Getting a readonly-rootfs use-case fully working still require a proper writable
> > filesystem to be mounted there, but how to do that is distro policy, and correct
> > OP-TEE can be at least be checked by mounting a tmpfs there.
>
> It might be better here to follow FHS and use a standard directory for
> the writable content (e.g. /var) instead. This should cover most
> distro configuration.

Right, that does make sense!

>
> > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > ---
> >  meta-arm/recipes-security/optee/optee-client.inc | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/meta-arm/recipes-security/optee/optee-client.inc b/meta-arm/recipes-security/optee/optee-client.inc
> > index f697386..0198433 100644
> > --- a/meta-arm/recipes-security/optee/optee-client.inc
> > +++ b/meta-arm/recipes-security/optee/optee-client.inc
> > @@ -24,6 +24,8 @@ do_install_append() {
> >      install -D -p -m0644 ${WORKDIR}/tee-supplicant.service ${D}${systemd_system_unitdir}/tee-supplicant.service
> >      install -D -p -m0755 ${WORKDIR}/tee-supplicant.sh ${D}${sysconfdir}/init.d/tee-supplicant
> >
> > +    install -d -m755 ${D}/data/tee
> > +
>
> You could give 'CFG_TEE_FS_PARENT_PATH=${localstatedir}/tee' to
> EXTRA_OEMAKE, for example.
>
> Cheers,
> --
> Ricardo Salveti



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

Re: [meta-arm] [PATCH 3/4] arm/optee-os: deploy tee.elf for u-boot

[Denys Dmytriyenko]

On Wed, Apr 14, 2021 at 09:47:06AM +0200, Yann Dirson wrote:
> Hi Denis,
> 
> Le mar. 13 avr. 2021 à 22:56, Denys Dmytriyenko <denis@denix.org> a écrit :
> >
> > On Tue, Apr 13, 2021 at 11:40:37AM +0200, Yann Dirson wrote:
> > > From: Yann Dirson <yann@blade-group.com>
> > >
> > > Integration of OP-TEE in the u-boot image is done with `TEE=tee.elf`.
> > > This can now be done in a BSP layer with something like this in
> > > `u-boot_%.bbappend`:
> >
> > Well, this is not very standardized and is platform-specific.
> >
> > For example, TI K3 platforms take tee-pager_v2.bin file into U-boot, not
> > tee.elf one. But tee.elf still gets deployed for debugging purposes...
> >
> > E.g. in meta-ti u-boot_%.bbappend:
> >
> > PACKAGECONFIG[optee] = "TEE=${STAGING_DIR_HOST}${nonarch_base_libdir}/firmware/tee-pager_v2.bin,,optee-os"
> > PACKAGECONFIG_append_k3 = " optee"
> >
> >
> > >  OPTEE_DEPENDS ??= ""
> > >  OPTEE_DEPENDS_rk3399 = " optee-os:do_deploy"
> > >
> > >  do_compile[depends] .= "${OPTEE_DEPENDS}"
> > >
> > >  do_compile_prepend_rk3399() {
> > >      export TEE=${DEPLOY_DIR_IMAGE}/optee/tee.elf
> > >  }
> >
> > To mee, the above PACKAGECONFIG approach is a bit cleaner...
> 
> Well, I did not like it either and went with a DISTRO_FEATURES approach,
> see my meta-rockchip patches on yocto ml.  It would be nice if it was generic
> enough, but your example above shows it probably needs some more
> refining anyway.
> 
> Eg. even the PACKAGECONFIG you show above is still BSP-specific.
> Maybe we could centralize in meta-arm the different ways to integrate
> op-tee, and get the BSP to choose one ?
> 
> >
> > In summary, I support availability of tee.elf, but besides do_deploy(), I
> > would also suggest adding it to do_install()
> 
> I must say I was puzzled by those optee files put it a package for installation
> in the target rootfs

No, they are not in the target rootfs, they don't have to be.
Getting files installed does put them in a package, which enables 
proper staging, so you can DEPENDS += "optee-os" and the files will 
be in recipe-sysroot, similar to my PACKAGECONFIG example above.
Whether the package gets installed in the target rootfs or not is 
completely orthogonal here.


> (but then as you say there seem to be many ways
> to integrate
> op-tee on different platforms).  If they're just useful for debugging,
> they would look like
> good candidates for a -dbg package: what use-case does the current optee-os
> binary package serve ?
> 
> >
> >
> > > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > > ---
> > >  meta-arm/recipes-security/optee/optee-os.inc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
> > > index 34f586a..db8428a 100644
> > > --- a/meta-arm/recipes-security/optee/optee-os.inc
> > > +++ b/meta-arm/recipes-security/optee/optee-os.inc
> > > @@ -58,7 +58,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> > >
> > >  do_deploy() {
> > >      install -d ${DEPLOYDIR}/optee
> > > -    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${DEPLOYDIR}/optee/
> > > +    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${B}/core/tee.elf ${DEPLOYDIR}/optee/
> > >  }
> > >
> > >  addtask deploy before do_build after do_install
> > > --
> > > 2.30.2
> > >

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

Re: [meta-arm] [PATCH 3/4] arm/optee-os: deploy tee.elf for u-boot

[Yann Dirson]

Le mer. 14 avr. 2021 à 17:01, Denys Dmytriyenko <denis@denix.org> a écrit :
>
> On Wed, Apr 14, 2021 at 09:47:06AM +0200, Yann Dirson wrote:
> > Hi Denis,
> >
> > Le mar. 13 avr. 2021 à 22:56, Denys Dmytriyenko <denis@denix.org> a écrit :
> > >
> > > On Tue, Apr 13, 2021 at 11:40:37AM +0200, Yann Dirson wrote:
> > > > From: Yann Dirson <yann@blade-group.com>
> > > >
> > > > Integration of OP-TEE in the u-boot image is done with `TEE=tee.elf`.
> > > > This can now be done in a BSP layer with something like this in
> > > > `u-boot_%.bbappend`:
> > >
> > > Well, this is not very standardized and is platform-specific.
> > >
> > > For example, TI K3 platforms take tee-pager_v2.bin file into U-boot, not
> > > tee.elf one. But tee.elf still gets deployed for debugging purposes...
> > >
> > > E.g. in meta-ti u-boot_%.bbappend:
> > >
> > > PACKAGECONFIG[optee] = "TEE=${STAGING_DIR_HOST}${nonarch_base_libdir}/firmware/tee-pager_v2.bin,,optee-os"
> > > PACKAGECONFIG_append_k3 = " optee"
> > >
> > >
> > > >  OPTEE_DEPENDS ??= ""
> > > >  OPTEE_DEPENDS_rk3399 = " optee-os:do_deploy"
> > > >
> > > >  do_compile[depends] .= "${OPTEE_DEPENDS}"
> > > >
> > > >  do_compile_prepend_rk3399() {
> > > >      export TEE=${DEPLOY_DIR_IMAGE}/optee/tee.elf
> > > >  }
> > >
> > > To mee, the above PACKAGECONFIG approach is a bit cleaner...
> >
> > Well, I did not like it either and went with a DISTRO_FEATURES approach,
> > see my meta-rockchip patches on yocto ml.  It would be nice if it was generic
> > enough, but your example above shows it probably needs some more
> > refining anyway.
> >
> > Eg. even the PACKAGECONFIG you show above is still BSP-specific.
> > Maybe we could centralize in meta-arm the different ways to integrate
> > op-tee, and get the BSP to choose one ?
> >
> > >
> > > In summary, I support availability of tee.elf, but besides do_deploy(), I
> > > would also suggest adding it to do_install()
> >
> > I must say I was puzzled by those optee files put it a package for installation
> > in the target rootfs
>
> No, they are not in the target rootfs, they don't have to be.
> Getting files installed does put them in a package, which enables
> proper staging, so you can DEPENDS += "optee-os" and the files will
> be in recipe-sysroot, similar to my PACKAGECONFIG example above.
> Whether the package gets installed in the target rootfs or not is
> completely orthogonal here.

I see what you mean.  However, a package is still originally the
"installable unit"
for meant for usage in a consistent filesystem, so we got a semantic
shift, then :).
If we have all those bootloader parts and other files already usable
through classical
DEPENDS, what good does it make to have them also exposed by do_deploy ?

In fact, using deployed artifacts in a recipe could even cause reproducibility
issues of the same kind we had before per-recipe sysroots.  Shouldn't we just
stop getting *any* file from DEPLOY_DIR_IMAGE in recipes ?

>
>
> > (but then as you say there seem to be many ways
> > to integrate
> > op-tee on different platforms).  If they're just useful for debugging,
> > they would look like
> > good candidates for a -dbg package: what use-case does the current optee-os
> > binary package serve ?
> >
> > >
> > >
> > > > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > > > ---
> > > >  meta-arm/recipes-security/optee/optee-os.inc | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
> > > > index 34f586a..db8428a 100644
> > > > --- a/meta-arm/recipes-security/optee/optee-os.inc
> > > > +++ b/meta-arm/recipes-security/optee/optee-os.inc
> > > > @@ -58,7 +58,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> > > >
> > > >  do_deploy() {
> > > >      install -d ${DEPLOYDIR}/optee
> > > > -    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${DEPLOYDIR}/optee/
> > > > +    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${B}/core/tee.elf ${DEPLOYDIR}/optee/
> > > >  }
> > > >
> > > >  addtask deploy before do_build after do_install
> > > > --
> > > > 2.30.2
> > > >
>
> --
> Regards,
> Denys Dmytriyenko <denis@denix.org>
> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
> Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

Re: [meta-arm] [PATCH 3/4] arm/optee-os: deploy tee.elf for u-boot

[Denys Dmytriyenko]

On Thu, Apr 15, 2021 at 09:44:32AM +0200, Yann Dirson wrote:
> Le mer. 14 avr. 2021 à 17:01, Denys Dmytriyenko <denis@denix.org> a écrit :
> >
> > On Wed, Apr 14, 2021 at 09:47:06AM +0200, Yann Dirson wrote:
> > > Hi Denis,
> > >
> > > Le mar. 13 avr. 2021 à 22:56, Denys Dmytriyenko <denis@denix.org> a écrit :
> > > >
> > > > On Tue, Apr 13, 2021 at 11:40:37AM +0200, Yann Dirson wrote:
> > > > > From: Yann Dirson <yann@blade-group.com>
> > > > >
> > > > > Integration of OP-TEE in the u-boot image is done with `TEE=tee.elf`.
> > > > > This can now be done in a BSP layer with something like this in
> > > > > `u-boot_%.bbappend`:
> > > >
> > > > Well, this is not very standardized and is platform-specific.
> > > >
> > > > For example, TI K3 platforms take tee-pager_v2.bin file into U-boot, not
> > > > tee.elf one. But tee.elf still gets deployed for debugging purposes...
> > > >
> > > > E.g. in meta-ti u-boot_%.bbappend:
> > > >
> > > > PACKAGECONFIG[optee] = "TEE=${STAGING_DIR_HOST}${nonarch_base_libdir}/firmware/tee-pager_v2.bin,,optee-os"
> > > > PACKAGECONFIG_append_k3 = " optee"
> > > >
> > > >
> > > > >  OPTEE_DEPENDS ??= ""
> > > > >  OPTEE_DEPENDS_rk3399 = " optee-os:do_deploy"
> > > > >
> > > > >  do_compile[depends] .= "${OPTEE_DEPENDS}"
> > > > >
> > > > >  do_compile_prepend_rk3399() {
> > > > >      export TEE=${DEPLOY_DIR_IMAGE}/optee/tee.elf
> > > > >  }
> > > >
> > > > To mee, the above PACKAGECONFIG approach is a bit cleaner...
> > >
> > > Well, I did not like it either and went with a DISTRO_FEATURES approach,
> > > see my meta-rockchip patches on yocto ml.  It would be nice if it was generic
> > > enough, but your example above shows it probably needs some more
> > > refining anyway.
> > >
> > > Eg. even the PACKAGECONFIG you show above is still BSP-specific.
> > > Maybe we could centralize in meta-arm the different ways to integrate
> > > op-tee, and get the BSP to choose one ?
> > >
> > > >
> > > > In summary, I support availability of tee.elf, but besides do_deploy(), I
> > > > would also suggest adding it to do_install()
> > >
> > > I must say I was puzzled by those optee files put it a package for installation
> > > in the target rootfs
> >
> > No, they are not in the target rootfs, they don't have to be.
> > Getting files installed does put them in a package, which enables
> > proper staging, so you can DEPENDS += "optee-os" and the files will
> > be in recipe-sysroot, similar to my PACKAGECONFIG example above.
> > Whether the package gets installed in the target rootfs or not is
> > completely orthogonal here.
> 
> I see what you mean.  However, a package is still originally the
> "installable unit"
> for meant for usage in a consistent filesystem, so we got a semantic
> shift, then :).
> If we have all those bootloader parts and other files already usable
> through classical
> DEPENDS, what good does it make to have them also exposed by do_deploy ?
> 
> In fact, using deployed artifacts in a recipe could even cause reproducibility
> issues of the same kind we had before per-recipe sysroots.  Shouldn't we just
> stop getting *any* file from DEPLOY_DIR_IMAGE in recipes ?

Consuming files from DEPLOY within recipes is not recommended. At least it 
wasn't originally...


> >
> >
> > > (but then as you say there seem to be many ways
> > > to integrate
> > > op-tee on different platforms).  If they're just useful for debugging,
> > > they would look like
> > > good candidates for a -dbg package: what use-case does the current optee-os
> > > binary package serve ?
> > >
> > > >
> > > >
> > > > > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > > > > ---
> > > > >  meta-arm/recipes-security/optee/optee-os.inc | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta-arm/recipes-security/optee/optee-os.inc b/meta-arm/recipes-security/optee/optee-os.inc
> > > > > index 34f586a..db8428a 100644
> > > > > --- a/meta-arm/recipes-security/optee/optee-os.inc
> > > > > +++ b/meta-arm/recipes-security/optee/optee-os.inc
> > > > > @@ -58,7 +58,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> > > > >
> > > > >  do_deploy() {
> > > > >      install -d ${DEPLOYDIR}/optee
> > > > > -    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${DEPLOYDIR}/optee/
> > > > > +    install -m 644 ${D}${nonarch_base_libdir}/firmware/* ${B}/core/tee.elf ${DEPLOYDIR}/optee/
> > > > >  }
> > > > >
> > > > >  addtask deploy before do_build after do_install
> > > > > --
> > > > > 2.30.2
> > > > >
> >
> > --
> > Regards,
> > Denys Dmytriyenko <denis@denix.org>
> > PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
> > Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964
> 
> 
> 
> -- 
> Yann Dirson <yann@blade-group.com>
> Blade / Shadow -- http://shadow.tech
> 

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964