Re: [PATCH 2/2] tee: optee: don't enumerate services if there ain't any

[Jens Wiklander]

On Wed, Nov 29, 2023 at 1:37 PM Etienne Carriere
 wrote:
>
> Change optee driver service enumeration to not enumerate (and
> allocate a zero sized shared memory buffer) when OP-TEE
> reports that there is no service to enumerate.
>
> This change fixes an existing issue that occurs when the such zero
> sized shared memory buffer allocated from malloc() has a physical
> address of offset 0 of a physical 4kB page. In such case, OP-TEE
> secure world refuses to register the zero-sized shared memory
> area and makes U-Boot optee service enumeration to fail.
>
> Fixes: 94ccfb78a4d6 ("drivers: tee: optee: discover OP-TEE services")
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 5308dd58ce..47f845cffe 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -139,6 +139,11 @@ static int enum_services(struct udevice *dev, struct 
> tee_shm **shm, size_t *coun
> if (ret)
> return ret;
>
> +   if (!shm_size) {
> +   *count = 0;
> +   return 0;
> +   }
> +
> ret = tee_shm_alloc(dev, shm_size, 0, shm);
> if (ret) {
> dev_err(dev, "Failed to allocated shared memory: %d\n", ret);
> @@ -185,14 +190,15 @@ static int bind_service_drivers(struct udevice *dev)
>
> ret = enum_services(dev, _list, _count, tee_sess,
> PTA_CMD_GET_DEVICES);
> -   if (!ret)
> +   if (!ret && service_count)
> ret = bind_service_list(dev, service_list, service_count);
>
> tee_shm_free(service_list);
> +   service_list = NULL;
>
> ret2 = enum_services(dev, _list, _count, tee_sess,
>  PTA_CMD_GET_DEVICES_SUPP);
> -   if (!ret2)
> +   if (!ret2 && service_count)
> ret2 = bind_service_list(dev, service_list, service_count);
>
> tee_shm_free(service_list);
> --
> 2.25.1
>

Re: [PATCH 1/2] tee: optee: don't fail on services enumeration failure

[Jens Wiklander]

On Wed, Nov 29, 2023 at 1:37 PM Etienne Carriere
 wrote:
>
> Change optee probe function to only warn when service enumeration
> sequence fails instead of reporting an optee driver probe failure.
> Indeed U-Boot can still use OP-TEE even if some OP-TEE services are
> not discovered.
>
> Fixes: 94ccfb78a4d6 ("drivers: tee: optee: discover OP-TEE services")
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 9a9b697e91..5308dd58ce 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -841,7 +841,7 @@ static int optee_probe(struct udevice *dev)
> if (IS_ENABLED(CONFIG_OPTEE_SERVICE_DISCOVERY)) {
> ret = bind_service_drivers(dev);
> if (ret)
> -   return ret;
> +   dev_warn(dev, "optee service enumeration failed: 
> %d\n", ret);
> } else if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> /*
>  * Discovery of TAs on the TEE bus is not supported in U-Boot:
> --
> 2.25.1
>

Looks good.
Reviewed-by: Jens Wiklander 

Thanks,
Jens

Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication

[Jens Wiklander]

Hi Abdellatif,

On Mon, Jul 31, 2023 at 1:46 PM Abdellatif El Khlifi
 wrote:
>
> Hi Ilias,
>
> On Mon, Jul 31, 2023 at 12:38:16PM +0300, Ilias Apalodimas wrote:
> > > > > > ...
> > > > > > Changelog:
> > > > > > ===
> > > > > >
> > > > > > v17:
> > > > > >
> > > > > > * show a debug message rather than an error when FF-A is not 
> > > > > > detected
> > > > > [snip]
> > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > index c5835e6ef6..8fbadb9201 100644
> > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE
> > > > > > stored as file /ubootefi.var on the EFI system partition.
> > > > > >
> > > > > >  config EFI_MM_COMM_TEE
> > > > > > - bool "UEFI variables storage service via OP-TEE"
> > > > > > - depends on OPTEE
> > > > > > + bool "UEFI variables storage service via the trusted world"
> > > > > > + depends on OPTEE && ARM_FFA_TRANSPORT
> > > > >
> > > > > You didn't get my changes in here however. If you can do 
> > > > > EFI_MM_COMM_TEE
> > > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) then
> > > > > you don't make this option depend on .  If FF-A is only
> > > > > for use here, you make FF-A depend on this, and the FF-A specific
> > > > > variable depend on ARM_FFA_TRANSPORT.
> > > >
> > > > Abdellatif hinted at what's going on here.  When I added this Kconfig
> > > > option to lx2160 FF-A wasn't implemented yet.
> > >
> > > The defconfig has existed since May 2020, which is when you added
> > > EFI_MM_COMM_TEE itself too.  So I think it's that no one did the check I
> > > did until now and saw this series was disabling what was on the other
> > > platform.
> > >
> > > > Since FF-A isn't a new
> > > > communication mechanism but builds upon the existing SMCs to build an
> > > > easier API, I asked Abdellatif to hide this complexity.
> > > > We had two options, either make Kconfig options for either FF-A or the
> > > > traditional SMCs and remove the dependencies,  or piggyback on FF-As
> > > > discovery mechanism and make the choice at runtime.  The latter has a
> > > > small impact on code size, but imho makes developers' life a lot
> > > > easier.
> > >
> > > I'm not sure how much you can do a run-time option here since you're
> > > setting a bunch of default values for FF-A to 0 in Kconfig.  If we're
> > > supposed to be able to get them at run time, we shouldn't need a Kconfig
> > > option at all.  I'm also not sure how valid a use case it is where we
> > > won't know at build time what the rest of the firmware stack supports
> > > here.
> > >
> >
> > That's a fair point.  FF-A in theory has APIs to discover memory.
> > Abdellatif, why do we need the Kconfigs for shared memory on FF-A?
>
> The statically carved out MM shared buffer address, size and offset cannot be 
> discovered by FF-A ABIs.
> The MM communication driver in U-Boot could allocate the buffer and share it 
> with the MM SP but
> we do not implement that support currently in either U-Boot or UEFI.
>
> Simon suggested we use build configs to set the buffer address, size and 
> offset since we don't want
> a DT node for the MM firmware.

In the OP-TEE driver we're allocating memory to share dynamically
using malloc() or memalign(). Why isn't the same approach possible
here?

Thanks,
Jens

[PATCH 8/8] asm-generic: simplify unaligned.h

[Jens Wiklander]

The get_unaligned()/put_unaligned() implementations are more
complex than necessary.

Move everything into one file and use a more compact implementation based
on packed struct access and byte swapping macros.

This patch is based on the Linux kernel commit 803f4e1eab7a
("asm-generic: simplify asm/unaligned.h") by Arnd Bergmann.

Signed-off-by: Jens Wiklander 
---
 include/asm-generic/unaligned.h | 89 +++--
 1 file changed, 73 insertions(+), 16 deletions(-)

diff --git a/include/asm-generic/unaligned.h b/include/asm-generic/unaligned.h
index 3d33a5a063e8..9e5d93ec3041 100644
--- a/include/asm-generic/unaligned.h
+++ b/include/asm-generic/unaligned.h
@@ -1,24 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 #ifndef _GENERIC_UNALIGNED_H
 #define _GENERIC_UNALIGNED_H
 
 #include 
 
-#include 
-#include 
-#include 
-
-/*
- * Select endianness
- */
-#if defined(__LITTLE_ENDIAN)
-#define get_unaligned  __get_unaligned_le
-#define put_unaligned  __put_unaligned_le
-#elif defined(__BIG_ENDIAN)
-#define get_unaligned  __get_unaligned_be
-#define put_unaligned  __put_unaligned_be
-#else
-#error invalid endian
-#endif
+#define __get_unaligned_t(type, ptr) ({
\
+   const struct { type x; } __packed * __pptr = (typeof(__pptr))(ptr); 
\
+   __pptr->x;  
\
+})
+
+#define __put_unaligned_t(type, val, ptr) do { 
\
+   struct { type x; } __packed * __pptr = (typeof(__pptr))(ptr);   
\
+   __pptr->x = (val);  
\
+} while (0)
+
+#define get_unaligned(ptr) __get_unaligned_t(typeof(*(ptr)), (ptr))
+#define put_unaligned(val, ptr) __put_unaligned_t(typeof(*(ptr)), (val), (ptr))
+
+static inline u16 get_unaligned_le16(const void *p)
+{
+   return le16_to_cpu(__get_unaligned_t(__le16, p));
+}
+
+static inline u32 get_unaligned_le32(const void *p)
+{
+   return le32_to_cpu(__get_unaligned_t(__le32, p));
+}
+
+static inline u64 get_unaligned_le64(const void *p)
+{
+   return le64_to_cpu(__get_unaligned_t(__le64, p));
+}
+
+static inline void put_unaligned_le16(u16 val, void *p)
+{
+   __put_unaligned_t(__le16, cpu_to_le16(val), p);
+}
+
+static inline void put_unaligned_le32(u32 val, void *p)
+{
+   __put_unaligned_t(__le32, cpu_to_le32(val), p);
+}
+
+static inline void put_unaligned_le64(u64 val, void *p)
+{
+   __put_unaligned_t(__le64, cpu_to_le64(val), p);
+}
+
+static inline u16 get_unaligned_be16(const void *p)
+{
+   return be16_to_cpu(__get_unaligned_t(__be16, p));
+}
+
+static inline u32 get_unaligned_be32(const void *p)
+{
+   return be32_to_cpu(__get_unaligned_t(__be32, p));
+}
+
+static inline u64 get_unaligned_be64(const void *p)
+{
+   return be64_to_cpu(__get_unaligned_t(__be64, p));
+}
+
+static inline void put_unaligned_be16(u16 val, void *p)
+{
+   __put_unaligned_t(__be16, cpu_to_be16(val), p);
+}
+
+static inline void put_unaligned_be32(u32 val, void *p)
+{
+   __put_unaligned_t(__be32, cpu_to_be32(val), p);
+}
+
+static inline void put_unaligned_be64(u64 val, void *p)
+{
+   __put_unaligned_t(__be64, cpu_to_be64(val), p);
+}
 
 /* Allow unaligned memory access */
 void allow_unaligned(void);
-- 
2.34.1

[PATCH 7/8] linux/unaligned: remove unused access_ok.h

[Jens Wiklander]

linux/unaligned/access_ok.h is unused, so remove it.

Signed-off-by: Jens Wiklander 
---
 include/linux/unaligned/access_ok.h | 66 -
 1 file changed, 66 deletions(-)
 delete mode 100644 include/linux/unaligned/access_ok.h

diff --git a/include/linux/unaligned/access_ok.h 
b/include/linux/unaligned/access_ok.h
deleted file mode 100644
index 5f46eee23c38..
--- a/include/linux/unaligned/access_ok.h
+++ /dev/null
@@ -1,66 +0,0 @@
-#ifndef _LINUX_UNALIGNED_ACCESS_OK_H
-#define _LINUX_UNALIGNED_ACCESS_OK_H
-
-#include 
-
-static inline u16 get_unaligned_le16(const void *p)
-{
-   return le16_to_cpup((__le16 *)p);
-}
-
-static inline u32 get_unaligned_le32(const void *p)
-{
-   return le32_to_cpup((__le32 *)p);
-}
-
-static inline u64 get_unaligned_le64(const void *p)
-{
-   return le64_to_cpup((__le64 *)p);
-}
-
-static inline u16 get_unaligned_be16(const void *p)
-{
-   return be16_to_cpup((__be16 *)p);
-}
-
-static inline u32 get_unaligned_be32(const void *p)
-{
-   return be32_to_cpup((__be32 *)p);
-}
-
-static inline u64 get_unaligned_be64(const void *p)
-{
-   return be64_to_cpup((__be64 *)p);
-}
-
-static inline void put_unaligned_le16(u16 val, void *p)
-{
-   *((__le16 *)p) = cpu_to_le16(val);
-}
-
-static inline void put_unaligned_le32(u32 val, void *p)
-{
-   *((__le32 *)p) = cpu_to_le32(val);
-}
-
-static inline void put_unaligned_le64(u64 val, void *p)
-{
-   *((__le64 *)p) = cpu_to_le64(val);
-}
-
-static inline void put_unaligned_be16(u16 val, void *p)
-{
-   *((__be16 *)p) = cpu_to_be16(val);
-}
-
-static inline void put_unaligned_be32(u32 val, void *p)
-{
-   *((__be32 *)p) = cpu_to_be32(val);
-}
-
-static inline void put_unaligned_be64(u64 val, void *p)
-{
-   *((__be64 *)p) = cpu_to_be64(val);
-}
-
-#endif /* _LINUX_UNALIGNED_ACCESS_OK_H */
-- 
2.34.1

[PATCH 6/8] fs/btrfs: use asm/unaligned.h

[Jens Wiklander]

Use asm/unaligned.h instead of linux/unaligned/access_ok.h for unaligned
access. This is needed on architectures that doesn't handle unaligned
accesses directly.

Signed-off-by: Jens Wiklander 
---
 fs/btrfs/crypto/hash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/crypto/hash.c b/fs/btrfs/crypto/hash.c
index 891a2974be05..0a0b35fe9b96 100644
--- a/fs/btrfs/crypto/hash.c
+++ b/fs/btrfs/crypto/hash.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.34.1

[PATCH 5/8] powerpc: use asm-generic/unaligned.h

[Jens Wiklander]

Powerpc configurations are apparently able to do unaligned accesses. But
in an attempt to clean up and handle unaligned accesses in the same way
we ignore that and use the common asm-generic/unaligned.h directly
instead.

Signed-off-by: Jens Wiklander 
---
 arch/powerpc/include/asm/unaligned.h | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/unaligned.h 
b/arch/powerpc/include/asm/unaligned.h
index 5f1b1e3c2137..7fb482abc383 100644
--- a/arch/powerpc/include/asm/unaligned.h
+++ b/arch/powerpc/include/asm/unaligned.h
@@ -1,16 +1,2 @@
-#ifndef _ASM_POWERPC_UNALIGNED_H
-#define _ASM_POWERPC_UNALIGNED_H
-
-#ifdef __KERNEL__
-
-/*
- * The PowerPC can do unaligned accesses itself in big endian mode.
- */
-#include 
-#include 
-
-#define get_unaligned  __get_unaligned_be
-#define put_unaligned  __put_unaligned_be
-
-#endif /* __KERNEL__ */
-#endif /* _ASM_POWERPC_UNALIGNED_H */
+/* SPDX-License-Identifier: GPL-2.0 */
+#include 
-- 
2.34.1

[PATCH 4/8] m68k: use asm-generic/unaligned.h

[Jens Wiklander]

M68k essentially duplicates the content of asm-generic/unaligned.h, with
an exception for non-Coldfire configurations. Coldfire configurations
are apparently able to do unaligned accesses. But in an attempt to clean
up and handle unaligned accesses in the same way we ignore that and use
the common asm-generic/unaligned.h directly instead.

Signed-off-by: Jens Wiklander 
---
 arch/m68k/include/asm/unaligned.h | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/m68k/include/asm/unaligned.h 
b/arch/m68k/include/asm/unaligned.h
index 328aa0c316c9..7fb482abc383 100644
--- a/arch/m68k/include/asm/unaligned.h
+++ b/arch/m68k/include/asm/unaligned.h
@@ -1,15 +1,2 @@
-#ifndef _ASM_M68K_UNALIGNED_H
-#define _ASM_M68K_UNALIGNED_H
-
-#ifdef CONFIG_COLDFIRE
-#include 
-#else
-#include 
-#endif
-
-#include 
-
-#define get_unaligned  __get_unaligned_be
-#define put_unaligned  __put_unaligned_be
-
-#endif /* _ASM_M68K_UNALIGNED_H */
+/* SPDX-License-Identifier: GPL-2.0 */
+#include 
-- 
2.34.1

[PATCH 3/8] mips: use asm-generic/unaligned.h

[Jens Wiklander]

Mips essentially duplicates the content of asm-generic/unaligned.h, so use
that file directly instead.

Signed-off-by: Jens Wiklander 
---
 arch/mips/include/asm/unaligned.h | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/mips/include/asm/unaligned.h 
b/arch/mips/include/asm/unaligned.h
index debb9cf7aba6..7fb482abc383 100644
--- a/arch/mips/include/asm/unaligned.h
+++ b/arch/mips/include/asm/unaligned.h
@@ -1,23 +1,2 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (C) 2007 Ralf Baechle (r...@linux-mips.org)
- */
-#ifndef _ASM_MIPS_UNALIGNED_H
-#define _ASM_MIPS_UNALIGNED_H
-
-#include 
-#if defined(__MIPSEB__)
-#define get_unaligned  __get_unaligned_be
-#define put_unaligned  __put_unaligned_be
-#elif defined(__MIPSEL__)
-#define get_unaligned  __get_unaligned_le
-#define put_unaligned  __put_unaligned_le
-#else
-#error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
-#endif
-
-#include 
-#include 
-#include 
-
-#endif /* _ASM_MIPS_UNALIGNED_H */
+#include 
-- 
2.34.1

[PATCH 2/8] sh: use asm-generic/unaligned.h

[Jens Wiklander]

Sh essentially duplicates the content of asm-generic/unaligned.h, so use
that file directly instead.

Signed-off-by: Jens Wiklander 
---
 arch/sh/include/asm/unaligned.h | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/sh/include/asm/unaligned.h b/arch/sh/include/asm/unaligned.h
index 5acf0819620e..7fb482abc383 100644
--- a/arch/sh/include/asm/unaligned.h
+++ b/arch/sh/include/asm/unaligned.h
@@ -1,20 +1,2 @@
-#ifndef _ASM_SH_UNALIGNED_H
-#define _ASM_SH_UNALIGNED_H
-
-/* Copy from linux-kernel. */
-
-/* Other than SH4A, SH can't handle unaligned accesses. */
-#include 
-#if defined(__BIG_ENDIAN__)
-#define get_unaligned   __get_unaligned_be
-#define put_unaligned   __put_unaligned_be
-#elif defined(__LITTLE_ENDIAN__)
-#define get_unaligned   __get_unaligned_le
-#define put_unaligned   __put_unaligned_le
-#endif
-
-#include 
-#include 
-#include 
-
-#endif /* _ASM_SH_UNALIGNED_H */
+/* SPDX-License-Identifier: GPL-2.0 */
+#include 
-- 
2.34.1

[PATCH 0/8] Cleanup unaligned access macros

[Jens Wiklander]

Hi,

There are two versions of get/set_unaligned, get_unaligned_be64,
put_unaligned_le64 etc in U-Boot causing confusion (and bugs).

In this patch-set, I'm trying to fix that with a single unified version of
the access macros to be used across all archs. This work is inspired by
similar changes in this Linux kernel by Arnd Bergman,
https://lore.kernel.org/lkml/20210514100106.3404011-1-a...@kernel.org/

Thanks,
Jens

Jens Wiklander (8):
  arm: use asm-generic/unaligned.h
  sh: use asm-generic/unaligned.h
  mips: use asm-generic/unaligned.h
  m68k: use asm-generic/unaligned.h
  powerpc: use asm-generic/unaligned.h
  fs/btrfs: use asm/unaligned.h
  linux/unaligned: remove unused access_ok.h
  asm-generic: simplify unaligned.h

 arch/arm/include/asm/unaligned.h | 21 +--
 arch/m68k/include/asm/unaligned.h| 17 +-
 arch/mips/include/asm/unaligned.h| 23 +--
 arch/powerpc/include/asm/unaligned.h | 18 +-
 arch/sh/include/asm/unaligned.h  | 22 +--
 fs/btrfs/crypto/hash.c   |  2 +-
 include/asm-generic/unaligned.h  | 89 +++-
 include/linux/unaligned/access_ok.h  | 66 -
 8 files changed, 83 insertions(+), 175 deletions(-)
 delete mode 100644 include/linux/unaligned/access_ok.h

-- 
2.34.1

[PATCH 1/8] arm: use asm-generic/unaligned.h

[Jens Wiklander]

Arm duplicates the content of asm-generic/unaligned.h, so use that file
directly instead.

Signed-off-by: Jens Wiklander 
---
 arch/arm/include/asm/unaligned.h | 21 ++---
 1 file changed, 2 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/unaligned.h b/arch/arm/include/asm/unaligned.h
index 0a228fb8eea8..7fb482abc383 100644
--- a/arch/arm/include/asm/unaligned.h
+++ b/arch/arm/include/asm/unaligned.h
@@ -1,19 +1,2 @@
-#ifndef _ASM_ARM_UNALIGNED_H
-#define _ASM_ARM_UNALIGNED_H
-
-#include 
-#include 
-#include 
-
-/*
- * Select endianness
- */
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-#define get_unaligned  __get_unaligned_le
-#define put_unaligned  __put_unaligned_le
-#else
-#define get_unaligned  __get_unaligned_be
-#define put_unaligned  __put_unaligned_be
-#endif
-
-#endif /* _ASM_ARM_UNALIGNED_H */
+/* SPDX-License-Identifier: GPL-2.0 */
+#include 
-- 
2.34.1

Re: [PATCH v4] common: avb_verify: prevent opening incorrect session

[Jens Wiklander]

On Fri, Jan 27, 2023 at 9:02 PM Ivan Khoronzhuk
 wrote:
>
> The arg->session is not valid if arg->ret != NULL, so can't be
> assigned, correct this.
>
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  common/avb_verify.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

>
> diff --git a/common/avb_verify.c b/common/avb_verify.c
> index 0520a71455..48ba8db51e 100644
> --- a/common/avb_verify.c
> +++ b/common/avb_verify.c
> @@ -619,10 +619,11 @@ static int get_open_session(struct AvbOpsData *ops_data)
> memset(, 0, sizeof(arg));
> tee_optee_ta_uuid_to_octets(arg.uuid, );
> rc = tee_open_session(tee, , 0, NULL);
> -   if (!rc) {
> -   ops_data->tee = tee;
> -   ops_data->session = arg.session;
> -   }
> +   if (rc || arg.ret)
> +   continue;
> +
> +   ops_data->tee = tee;
> +   ops_data->session = arg.session;
> }
>
> return 0;
> --
> 2.34.1
>

Re: [PATCH v2] common: avb_verify: prevent opening incorrect session

[Jens Wiklander]

On Mon, Jan 23, 2023 at 5:09 PM Ivan Khoronzhuk
 wrote:
>
> On Mon, Jan 23, 2023 at 04:34:33PM +0100, Jens Wiklander wrote:
> >On Mon, Jan 23, 2023 at 04:51:29PM +0200, Ivan Khoronzhuk wrote:
> >> The arg->session is not valid if arg->ret != NULL, so can't be
> >> assigned. Leave retry for just "ret" error to save same behaviour.
> >>
> >> Signed-off-by: Ivan Khoronzhuk 
> >> ---
> >>  common/avb_verify.c | 12 
> >>  1 file changed, 8 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/common/avb_verify.c b/common/avb_verify.c
> >> index 0520a71455..97451592f5 100644
> >> --- a/common/avb_verify.c
> >> +++ b/common/avb_verify.c
> >> @@ -619,10 +619,14 @@ static int get_open_session(struct AvbOpsData 
> >> *ops_data)
> >>  memset(, 0, sizeof(arg));
> >>  tee_optee_ta_uuid_to_octets(arg.uuid, );
> >>  rc = tee_open_session(tee, , 0, NULL);
> >> -if (!rc) {
> >> -ops_data->tee = tee;
> >> -ops_data->session = arg.session;
> >> -}
> >> +if (rc)
> >> +continue;
> >> +
> >> +if (arg.ret)
> >> +return -EIO;
> >> +
> >> +ops_data->tee = tee;
> >> +ops_data->session = arg.session;
> >>  }
> >>
> >>  return 0;
> >
> >It looks like this function is still slightly broken. The function
> >should, if I understand it correctly, return usable tee and session
> >pointers on success, else return an error code. The unconditional return
> >0 at the end doesn't seem right.
> >
> >Thanks,
> >Jens
>
> It doesn't return, it loops infinitely...
> Yes, it looks so, but it's how it works. I don't see a reason why the
> function must loop trying to open the session that potentially never will be
> opened. But this is how it's implemented and I didn't wont to change this
> behaviour that can have some "sacral" roots, only add a fix I bother, I've

No worries, no need to be bug compatible here. :-)

> mentioned it in the comment. Better would be drop this loop ofc and add the
> following:
>
> +   if (ret || arg.ret)
> +   return -EIO;

A loop is needed to find the TEE device. Right now I guess there's
only one and it will be found in the first round.

>
> I can do this in v3 if you don't mind.

Yes, please fix the function to return an error if a session can't be found.

Thanks,
Jens

Re: [PATCH v2] common: avb_verify: prevent opening incorrect session

[Jens Wiklander]

On Mon, Jan 23, 2023 at 04:51:29PM +0200, Ivan Khoronzhuk wrote:
> The arg->session is not valid if arg->ret != NULL, so can't be
> assigned. Leave retry for just "ret" error to save same behaviour.
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  common/avb_verify.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/common/avb_verify.c b/common/avb_verify.c
> index 0520a71455..97451592f5 100644
> --- a/common/avb_verify.c
> +++ b/common/avb_verify.c
> @@ -619,10 +619,14 @@ static int get_open_session(struct AvbOpsData *ops_data)
>   memset(, 0, sizeof(arg));
>   tee_optee_ta_uuid_to_octets(arg.uuid, );
>   rc = tee_open_session(tee, , 0, NULL);
> - if (!rc) {
> - ops_data->tee = tee;
> - ops_data->session = arg.session;
> - }
> + if (rc)
> + continue;
> +
> + if (arg.ret)
> + return -EIO;
> +
> + ops_data->tee = tee;
> + ops_data->session = arg.session;
>   }
>  
>   return 0;

It looks like this function is still slightly broken. The function
should, if I understand it correctly, return usable tee and session
pointers on success, else return an error code. The unconditional return
0 at the end doesn't seem right.

Thanks,
Jens

Re: [PATCH] common: avb_verify: prevent opening incorrect session

[Jens Wiklander]

On Sun, Jan 22, 2023 at 3:41 AM Ivan Khoronzhuk
 wrote:
>
> The arg->session is not valid if arg->ret != NULL, so can't be
> assigned. Leave retry for just "ret" error to save same behaviour.
>
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  common/avb_verify.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/common/avb_verify.c b/common/avb_verify.c
> index 0520a71455..05d5a97896 100644
> --- a/common/avb_verify.c
> +++ b/common/avb_verify.c
> @@ -619,10 +619,14 @@ static int get_open_session(struct AvbOpsData *ops_data)
> memset(, 0, sizeof(arg));
> tee_optee_ta_uuid_to_octets(arg.uuid, );
> rc = tee_open_session(tee, , 0, NULL);
> -   if (!rc) {
> -   ops_data->tee = tee;
> -   ops_data->session = arg.session;
> -   }
> +   if (rc)
> +   continue;
> +
> +   if (arg.ret)
> +   return AVB_IO_RESULT_ERROR_IO;

This should probably be an errno define instead since that's what is used above.

Cheers,
Jens

> +
> +   ops_data->tee = tee;
> +   ops_data->session = arg.session;
> }
>
> return 0;
> --
> 2.34.1
>

Re: [PATCH] MAINTAINERS: add a new entry on TEE MAINTAINERS

[Jens Wiklander]

On Thu, Jan 19, 2023 at 4:11 PM Ilias Apalodimas
 wrote:
>
> Since I do have a look on TEE patches regardless and Jens doesn't have
> his own tree, add myself as a co-maintainer.  I'll be carrying over the
> TEE related patches from now own.  While at it add the maintenance tree

from now on.

> for TPM
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)

With the spelling error in the commit message fixed.

Reviewed-by: Jens Wiklander 

Cheers,
Jens

>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b2de50ccfc88..8dcce886b87f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1452,6 +1452,7 @@ F:configs/j721s2_hs_evm_r5_defconfig
>  TPM DRIVERS
>  M: Ilias Apalodimas 
>  S: Maintained
> +T: git https://source.denx.de/u-boot/custodians/u-boot-tpm.git
>  F: drivers/tpm/
>
>  TQ GROUP
> @@ -1461,6 +1462,8 @@ T:    git git://git.denx.de/u-boot-tq-group.git
>
>  TEE
>  M: Jens Wiklander 
> +M: Ilias Apalodimas 
> +T: git https://source.denx.de/u-boot/custodians/u-boot-tpm.git
>  S: Maintained
>  F: drivers/tee/
>  F: include/tee.h
> --
> 2.38.1
>

Re: [PATCH] tpm2: ftpm: add the device in the OP-TEE services list

[Jens Wiklander]

On Thu, Jan 19, 2023 at 3:36 PM Ilias Apalodimas
 wrote:
>
> commit fe8a4ed0111073 ("tee: optee: discover services dependent on 
> tee-supplicant")
> is trying to automatically scan and add TAs that are presented on pseudo
> bus from the secure world.
> In orer to be able to list and compare the scanned devices the available 
> drivers
In order to...

> have to register themselves on the op-tee service list.
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  drivers/tpm/tpm2_ftpm_tee.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tpm/tpm2_ftpm_tee.c b/drivers/tpm/tpm2_ftpm_tee.c
> index 3c4c12983daa..f0deaec5b076 100644
> --- a/drivers/tpm/tpm2_ftpm_tee.c
> +++ b/drivers/tpm/tpm2_ftpm_tee.c
> @@ -18,10 +18,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "tpm_tis.h"
>  #include "tpm2_ftpm_tee.h"
>
> +OPTEE_SERVICE_DRIVER(optee_ftpm, TA_FTPM_UUID, "ftpm_tee");
>  /**
>   * ftpm_tee_transceive() - send fTPM commands and retrieve fTPM response.
>   * @sendbuf - address of the data to send, byte by byte
> --
> 2.38.1
>

With the spelling error in the commit message fixed.

Reviewed-by: Jens Wiklander 

Cheers,
Jens

Re: [PATCH] tee: optee: fix uuid comparisons on service discovery

[Jens Wiklander]

On Thu, Jan 19, 2023 at 10:21 AM Ilias Apalodimas
 wrote:
>
> When comparing UUIDs for discovered services we only compare up to the
> ptr size instead of the entire UUID
>
> Fixes: 94ccfb78a4d61 ("drivers: tee: optee: discover OP-TEE services")
> Signed-off-by: Ilias Apalodimas 
> ---
>  drivers/tee/optee/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Jens Wiklander 

Cheers,
Jens

>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 88e23d252bcd..9a9b697e91f5 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -73,7 +73,7 @@ static struct optee_service *find_service_driver(const 
> struct tee_optee_ta_uuid
>
> for (idx = 0; idx < service_cnt; idx++, service++) {
> tee_optee_ta_uuid_to_octets(loc_uuid, >uuid);
> -   if (!memcmp(uuid, loc_uuid, sizeof(uuid)))
> +   if (!memcmp(uuid, loc_uuid, sizeof(*uuid)))
> return service;
> }
>
> --
> 2.38.1
>

Re: [PATCH] tee: optee: fix a print error on rng probing

[Jens Wiklander]

On Wed, Jan 18, 2023 at 11:51 PM Etienne Carriere
 wrote:
>
> On Wed, 18 Jan 2023 at 19:54, Ilias Apalodimas
>  wrote:
> >
> > Thanks Patrick,
> >
> > On Wed, 18 Jan 2023 at 18:53, Patrick DELAUNAY
> >  wrote:
> > >
> > > Hi
> > >
> > > On 1/18/23 16:38, Ilias Apalodimas wrote:
> > > > If we fail to probe the optee-rng device, we print a wrong message
> > > > referring to the firmware tpm.
> > > >
> > > > Signed-off-by: Ilias Apalodimas 
> > > > ---
> > > >   drivers/tee/optee/core.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > > > index a813a84a4f16..88e23d252bcd 100644
> > > > --- a/drivers/tee/optee/core.c
> > > > +++ b/drivers/tee/optee/core.c
> > > > @@ -850,7 +850,7 @@ static int optee_probe(struct udevice *dev)
> > > >   ret = device_bind_driver_to_node(dev, "optee-rng", 
> > > > "optee-rng",
> > > >dev_ofnode(dev), NULL);
> > > >   if (ret)
> > > > - dev_warn(dev, "ftpm_tee failed to bind: %d\n", 
> > > > ret);
> > > > + dev_warn(dev, "optee-rng failed to bind: %d\n", 
> > > > ret);
> > > >   }
> > > >
> > > >   return 0;
> > >
> > >
> > > I think you can add:
> > >
> > > Fixes: 476a3d58dfeb ("tee: optee: don't fail probe because of optee-rng")
> > >
> > >
> > > Reviewed-by: Patrick Delaunay 
> >
> > Sure I'll wait for additional reviews etc and respin
>
> Reviewed-by: Etienne Carriere 

Reviewed-by: Jens Wiklander 

Cheers,
Jens

> Sorry for that :|
>
> etienne
>
> >
> > Cheers
> > /Ilias
> > >
> > > Thanks
> > > Patrick
> > >
> > >

Re: [PATCH 1/2] tee: optee: don't fail probe because of optee-rng

[Jens Wiklander]

On Wed, Dec 7, 2022 at 4:30 PM Etienne Carriere
 wrote:
>
> Fixes optee-rng driver bind sequence in optee driver to print a warning
> message but not report an error status when a optee-rng service driver
> fails to be bound as the optee driver itself is still fully functional.
>
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 9240277579..604fd1414f 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -834,7 +834,7 @@ static int optee_probe(struct udevice *dev)
>  */
> ret = device_bind_driver(dev, "optee-rng", "optee-rng", NULL);
> if (ret)
> -   return ret;
> +   dev_warn(dev, "ftpm_tee failed to bind: %d\n", ret);
> }
>
> return 0;
> --
> 2.25.1
>

Re: [PATCH 2/2] tee: optee: discover services dependent on tee-supplicant

[Jens Wiklander]

On Wed, Dec 7, 2022 at 4:30 PM Etienne Carriere
 wrote:
>
> Makes OP-TEE to enumerate also services depending on tee-supplicant
> support in U-Boot. This change allows OP-TEE services like fTPM TA
> to be discovered and get a TPM device registered in U-Boot.
>
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 32 +++-
>  1 file changed, 23 insertions(+), 9 deletions(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 604fd1414f..b21031d7d8 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -102,13 +102,14 @@ static int bind_service_list(struct udevice *dev, 
> struct tee_shm *service_list,
> return 0;
>  }
>
> -static int __enum_services(struct udevice *dev, struct tee_shm *shm, size_t 
> *shm_size, u32 tee_sess)
> +static int __enum_services(struct udevice *dev, struct tee_shm *shm, size_t 
> *shm_size, u32 tee_sess,
> +  unsigned int pta_cmd)
>  {
> struct tee_invoke_arg arg = { };
> struct tee_param param = { };
> int ret = 0;
>
> -   arg.func = PTA_CMD_GET_DEVICES;
> +   arg.func = pta_cmd;
> arg.session = tee_sess;
>
> /* Fill invoke cmd params */
> @@ -118,7 +119,7 @@ static int __enum_services(struct udevice *dev, struct 
> tee_shm *shm, size_t *shm
>
> ret = tee_invoke_func(dev, , 1, );
> if (ret || (arg.ret && arg.ret != TEE_ERROR_SHORT_BUFFER)) {
> -   dev_err(dev, "PTA_CMD_GET_DEVICES invoke function err: 
> 0x%x\n", arg.ret);
> +   dev_err(dev, "Enumeration command 0x%x failed: 0x%x\n", 
> pta_cmd, arg.ret);
> return -EINVAL;
> }
>
> @@ -127,12 +128,13 @@ static int __enum_services(struct udevice *dev, struct 
> tee_shm *shm, size_t *shm
> return 0;
>  }
>
> -static int enum_services(struct udevice *dev, struct tee_shm **shm, size_t 
> *count, u32 tee_sess)
> +static int enum_services(struct udevice *dev, struct tee_shm **shm, size_t 
> *count, u32 tee_sess,
> +unsigned int pta_cmd)
>  {
> size_t shm_size = 0;
> int ret;
>
> -   ret = __enum_services(dev, NULL, _size, tee_sess);
> +   ret = __enum_services(dev, NULL, _size, tee_sess, pta_cmd);
> if (ret)
> return ret;
>
> @@ -142,7 +144,7 @@ static int enum_services(struct udevice *dev, struct 
> tee_shm **shm, size_t *coun
> return ret;
> }
>
> -   ret = __enum_services(dev, *shm, _size, tee_sess);
> +   ret = __enum_services(dev, *shm, _size, tee_sess, pta_cmd);
> if (!ret)
> *count = shm_size / sizeof(struct tee_optee_ta_uuid);
>
> @@ -174,20 +176,32 @@ static int bind_service_drivers(struct udevice *dev)
> struct tee_shm *service_list = NULL;
> size_t service_count;
> u32 tee_sess;
> -   int ret;
> +   int ret, ret2;
>
> ret = open_enum_session(dev, _sess);
> if (ret)
> return ret;
>
> -   ret = enum_services(dev, _list, _count, tee_sess);
> +   ret = enum_services(dev, _list, _count, tee_sess,
> +   PTA_CMD_GET_DEVICES);
> if (!ret)
> ret = bind_service_list(dev, service_list, service_count);
>
> tee_shm_free(service_list);
> +
> +   ret2 = enum_services(dev, _list, _count, tee_sess,
> +PTA_CMD_GET_DEVICES_SUPP);
> +   if (!ret2)
> +   ret2 = bind_service_list(dev, service_list, service_count);
> +
> +   tee_shm_free(service_list);
> +
> tee_close_session(dev, tee_sess);
>
> -   return ret;
> +   if (ret)
> +   return ret;
> +
> +   return ret2;
>  }
>
>  /**
> --
> 2.25.1
>

Re: [PATCH v7 03/10] arm_ffa: introduce Arm FF-A low-level driver

[Jens Wiklander]

On Fri, Nov 11, 2022 at 02:36:11PM +, Abdellatif El Khlifi wrote:
> On Wed, Nov 09, 2022 at 12:51:26PM +0100, Jens Wiklander wrote:
> > On Mon, Nov 07, 2022 at 07:20:48PM +, Abdellatif El Khlifi wrote:
[snip]
> > > +/**
> > > + * ffa_msg_send_direct_req - FFA_MSG_SEND_DIRECT_{REQ,RESP} handler 
> > > function
> > > + * @dst_part_id: destination partition ID
> > > + * @msg: pointer to the message data preallocated by the client (in/out)
> > > + * @is_smc64: select 64-bit or 32-bit FF-A ABI
> > > + *
> > > + * This function implements FFA_MSG_SEND_DIRECT_{REQ,RESP}
> > > + * FF-A functions.
> > > + *
> > > + * FFA_MSG_SEND_DIRECT_REQ is used to send the data to the secure 
> > > partition.
> > > + * The response from the secure partition is handled by reading the
> > > + * FFA_MSG_SEND_DIRECT_RESP arguments.
> > > + *
> > > + * The maximum size of the data that can be exchanged is 40 bytes which 
> > > is
> > > + * sizeof(struct ffa_send_direct_data) as defined by the FF-A 
> > > specification 1.0
> > > + * in the section relevant to FFA_MSG_SEND_DIRECT_{REQ,RESP}
> > > + *
> > > + * Return:
> > > + *
> > > + * 0 on success. Otherwise, failure
> > > + */
> > > +static int ffa_msg_send_direct_req(u16 dst_part_id, struct 
> > > ffa_send_direct_data *msg, bool is_smc64)
> > > +{
> > > + ffa_value_t res = {0};
> > > + int ffa_errno;
> > > + u64 req_mode, resp_mode;
> > > +
> > > + if (!ffa_priv_data || !ffa_priv_data->invoke_ffa_fn)
> > > + return -EINVAL;
> > > +
> > > + /* No partition installed */
> > > + if (!ffa_priv_data->partitions.count || 
> > > !ffa_priv_data->partitions.descs)
> > > + return -ENODEV;
> > 
> > This check isn't needed. What if the partition ID is known by other
> > means?
> 
> I'm happy to remove this check. I'd like to add a comment explaining
> what the other means are. Could you please explain what are they ?

In some systems perhaps you have well known partition ids reserved for
certain services.

> 
> > 
> > > +
> > > + if (is_smc64) {
> > > + req_mode = FFA_SMC_64(FFA_MSG_SEND_DIRECT_REQ);
> > > + resp_mode = FFA_SMC_64(FFA_MSG_SEND_DIRECT_RESP);
> > > + } else {
> > > + req_mode = FFA_SMC_32(FFA_MSG_SEND_DIRECT_REQ);
> > > + resp_mode = FFA_SMC_32(FFA_MSG_SEND_DIRECT_RESP);
> > > + }
> > > +
> > > + ffa_priv_data->invoke_ffa_fn((ffa_value_t){
> > > + .a0 = req_mode,
> > > + .a1 = PREP_SELF_ENDPOINT_ID(ffa_priv_data->id) |
> > > + PREP_PART_ENDPOINT_ID(dst_part_id),
> > > + .a2 = 0,
> > > + .a3 = msg->data0,
> > > + .a4 = msg->data1,
> > > + .a5 = msg->data2,
> > > + .a6 = msg->data3,
> > > + .a7 = msg->data4,
> > > + }, );
> > > +
> > > + while (res.a0 == FFA_SMC_32(FFA_INTERRUPT))
> > > + ffa_priv_data->invoke_ffa_fn((ffa_value_t){
> > > + .a0 = FFA_SMC_32(FFA_RUN),
> > > + .a1 = res.a1,
> > > + }, );
> > > +
> > > + if (res.a0 == FFA_SMC_32(FFA_SUCCESS)) {
> > > + /* Message sent with no response */
> > > + return 0;
> > > + }
> > > +
> > > + if (res.a0 == resp_mode) {
> > > + /*
> > > +  * Message sent with response
> > > +  * extract the return data
> > > +  */
> > > + msg->data0 = res.a3;
> > > + msg->data1 = res.a4;
> > > + msg->data2 = res.a5;
> > > + msg->data3 = res.a6;
> > > + msg->data4 = res.a7;
> > > +
> > > + return 0;
> > > + }
> > > +
> > > + ffa_errno = res.a2;
> > > + return ffa_to_std_errno(ffa_errno);
> > > +}
> > > +

[snip]

> > > +/**
> > > + * ffa_bus_prvdata_get - bus driver private data getter
> > > + *
> > > + * Return:
> > > + * This function returns a pointer to the main private data structure
> > > + */
> > > +struct ffa_prvdata **ffa_bus_prvdata_get(void)
> > 
> > Why a pointer to a pointer, isn't "struct ff

Re: [PATCH v7 03/10] arm_ffa: introduce Arm FF-A low-level driver

[Jens Wiklander]

On Mon, Nov 07, 2022 at 07:20:48PM +, Abdellatif El Khlifi wrote:
> Add the core driver implementing Arm Firmware Framework for Armv8-A v1.0
> 
> The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
> 
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
> 
> The driver uses SMC32 calling convention which means using the first
> 32-bit data of the Xn registers.
> 
> All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
> which has 64-bit version supported.
> 
> Both 32-bit and 64-bit direct messaging are supported which allows both
> 32-bit and 64-bit clients to use the FF-A bus.
> 
> In U-Boot FF-A design, FF-A is considered as a discoverable bus.
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
> 
> The driver exports its operations to be used by upper layers.
> 
> Exported operations:
> 
> - partition_info_get
> - sync_send_receive
> - rxtx_unmap
> 
> For more details please refer to the driver documentation [2].
> 
> [1]: https://developer.arm.com/documentation/den0077/latest/
> [2]: doc/arch/arm64.ffa.rst
> 
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> 
> ---
> 
> Changelog:
> ===
> 
> v7:
> 
> * add support for 32-bit direct messaging
> * rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
> * improve the declaration of error handling mapping
> * stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported
> 
> v6:
> 
> * drop use of EFI runtime support (We decided with Linaro to add this later)
> * drop discovery from initcalls (discovery will be on demand by FF-A users)
> * set the alignment of the RX/TX buffers to the larger translation granule 
> size
> * move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
> * update the documentation and move it to doc/arch/arm64.ffa.rst
> 
> v4:
> 
> * add doc/README.ffa.drv
> * moving the FF-A driver work to drivers/firmware/arm-ffa
> * use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
>   #if defined by #if CONFIG_IS_ENABLED
> * improving error handling by mapping the FF-A errors to standard errors
>   and logs
> * replacing panics with an error log and returning an error code
> * improving features discovery in FFA_FEATURES by introducing
>   rxtx_min_pages private data field
> * add ffa_remove and ffa_unbind functions
> * improve how the driver behaves when bus discovery is done more than
>   once
> 
> v3:
> 
> * align the interfaces of the U-Boot FF-A driver with those in the linux
>   FF-A driver
> * remove the FF-A helper layer
> * make the U-Boot FF-A driver independent from EFI
> * provide an optional config that enables copying the driver data to EFI
>   runtime section at ExitBootServices service
> * use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
> 
> v2:
> 
> * make FF-A bus discoverable using device_{bind, probe} APIs
> * remove device tree support
> 
> v1:
> 
> * introduce FF-A bus driver with device tree support
> 
> MAINTAINERS   |7 +
>  doc/arch/arm64.ffa.rst|  218 
>  doc/arch/index.rst|1 +
>  drivers/Kconfig   |2 +
>  drivers/Makefile  |1 +
>  drivers/firmware/arm-ffa/Kconfig  |   30 +
>  drivers/firmware/arm-ffa/Makefile |6 +
>  drivers/firmware/arm-ffa/arm-ffa-uclass.c |   16 +
>  drivers/firmware/arm-ffa/arm_ffa_prv.h|  205 
>  drivers/firmware/arm-ffa/core.c   | 1310 +
>  include/arm_ffa.h |   93 ++
>  include/dm/uclass-id.h|4 +
>  12 files changed, 1893 insertions(+)
>  create mode 100644 doc/arch/arm64.ffa.rst
>  create mode 100644 drivers/firmware/arm-ffa/Kconfig
>  create mode 100644 drivers/firmware/arm-ffa/Makefile
>  create mode 100644 drivers/firmware/arm-ffa/arm-ffa-uclass.c
>  create mode 100644 drivers/firmware/arm-ffa/arm_ffa_prv.h
>  create mode 100644 drivers/firmware/arm-ffa/core.c
>  create mode 100644 include/arm_ffa.h
> 
> diff --git a/MAINTAINERS b/MA

Re: [PATCH v6 03/10] arm_ffa: introduce Arm FF-A low-level driver

[Jens Wiklander]

On Thu, Oct 13, 2022 at 11:38:50AM +0100, Abdellatif El Khlifi wrote:
> Add the core driver implementing Arm Firmware Framework for Armv8-A v1.0
> 
> The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
> 
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
> 
> 32-bit version of the ABIs is supported and 64-bit version of FFA_RXTX_MAP
> and FFA_MSG_SEND_DIRECT_{REQ, RESP}.
> 
> In u-boot FF-A design, FF-A is considered as a discoverable bus.

U-Boot

> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
> 
> The driver exports its operations to be used by upper layers.
> 
> Exported operations:
> 
> - partition_info_get
> - sync_send_receive
> - rxtx_unmap
> 
> [1]: https://developer.arm.com/documentation/den0077/latest/
> 
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> 
> ---
> 
> Changelog:
> ===
> 
> v6:
> 
> * drop use of EFI runtime support (We decided with Linaro to add this later)
> * drop discovery from initcalls (discovery will be on demand by FF-A users)
> * set the alignment of the RX/TX buffers to the larger translation granule 
> size
> * move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
> * update the documentation and move it to doc/arch/arm64.ffa.rst
> 
> v4:
> 
> * add doc/README.ffa.drv
> * moving the FF-A driver work to drivers/firmware/arm-ffa
> * use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
>   #if defined by #if CONFIG_IS_ENABLED
> * improving error handling by mapping the FF-A errors to standard errors
>   and logs
> * replacing panics with an error log and returning an error code
> * improving features discovery in FFA_FEATURES by introducing
>   rxtx_min_pages private data field
> * add ffa_remove and ffa_unbind functions
> * improve how the driver behaves when bus discovery is done more than
>   once
> 
> v3:
> 
> * align the interfaces of the u-boot FF-A driver with those in the linux
>   FF-A driver
> * remove the FF-A helper layer
> * make the u-boot FF-A driver independent from EFI
> * provide an optional config that enables copying the driver data to EFI
>   runtime section at ExitBootServices service
> * use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
> 
> v2:
> 
> * make FF-A bus discoverable using device_{bind, probe} APIs
> * remove device tree support
> 
> v1:
> 
> * introduce FF-A bus driver with device tree support
> 
>  MAINTAINERS   |7 +
>  doc/arch/arm64.ffa.rst|  207 
>  doc/arch/index.rst|1 +
>  drivers/Kconfig   |2 +
>  drivers/Makefile  |1 +
>  drivers/firmware/arm-ffa/Kconfig  |   30 +
>  drivers/firmware/arm-ffa/Makefile |6 +
>  drivers/firmware/arm-ffa/arm-ffa-uclass.c |   16 +
>  drivers/firmware/arm-ffa/arm_ffa_prv.h|  196 +++
>  drivers/firmware/arm-ffa/core.c   | 1337 +
>  include/arm_ffa.h |   93 ++
>  include/dm/uclass-id.h|4 +
>  12 files changed, 1900 insertions(+)
>  create mode 100644 doc/arch/arm64.ffa.rst
>  create mode 100644 drivers/firmware/arm-ffa/Kconfig
>  create mode 100644 drivers/firmware/arm-ffa/Makefile
>  create mode 100644 drivers/firmware/arm-ffa/arm-ffa-uclass.c
>  create mode 100644 drivers/firmware/arm-ffa/arm_ffa_prv.h
>  create mode 100644 drivers/firmware/arm-ffa/core.c
>  create mode 100644 include/arm_ffa.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a26b36c7c2..496f47a516 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -248,6 +248,13 @@ F:   drivers/net/cortina_ni.h
>  F:   drivers/net/phy/ca_phy.c
>  F:   configs/cortina_presidio-asic-pnand_defconfig
>  
> +ARM FF-A
> +M:   Abdellatif El Khlifi 
> +S:   Maintained
> +F:   doc/arch/arm64.ffa.rst
> +F:   drivers/firmware/arm-ffa/
> +F:   include/arm_ffa.h
> +
>  ARM FREESCALE IMX
>  M:   Stefano Babic 
>  M:   Fabio Estevam 
> diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst
> new file mode 100644
>

Re: [PATCH v6 01/10] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers

[Jens Wiklander]

On Thu, Oct 13, 2022 at 11:38:48AM +0100, Abdellatif El Khlifi wrote:
> add support for x0-x17 registers used by the SMC calls
> 
> In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
> Results are returned in x0-x17.
> 
> This work is inspired from the following kernel commit:
> 
> arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
> 
> [1]: 
> https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=
> 
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> 
> ---
> 
> Changelog:
> ===
> 
> v4:
> 
> * rename the commit title and improve description
>   new commit title: the current
> 
> v3:
> 
> * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2
>   commit title:
>   arm64: smccc: add Xn registers support used by SMC calls
> 
> arch/arm/cpu/armv8/smccc-call.S | 53 +
>  arch/arm/lib/asm-offsets.c  | 14 +
>  include/linux/arm-smccc.h   | 43 ++
>  3 files changed, 110 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index dc92b28777..ec6f299bc9 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -1,6 +1,8 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  /*
>   * Copyright (c) 2015, Linaro Limited
> + * (C) Copyright 2022 ARM Limited
> + * Abdellatif El Khlifi 
>   */
>  #include 
>  #include 
> @@ -45,3 +47,54 @@ ENDPROC(__arm_smccc_smc)
>  ENTRY(__arm_smccc_hvc)
>   SMCCC   hvc
>  ENDPROC(__arm_smccc_hvc)
> +
> +#ifdef CONFIG_ARM64
> +
> + .macro SMCCC_1_2 instr
> + /* Save `res` and free a GPR that won't be clobbered */
> + stp x1, x19, [sp, #-16]!
> +
> + /* Ensure `args` won't be clobbered while loading regs in next step */
> + mov x19, x0
> +
> + /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */
> + ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
> + ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
> + ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
> + ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
> + ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
> + ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
> + ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
> + ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> + ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
> +
> + \instr #0
> +
> + /* Load the `res` from the stack */
> + ldr x19, [sp]
> +
> + /* Store the registers x0 - x17 into the result structure */
> + stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS]
> + stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS]
> + stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS]
> + stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS]
> + stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS]
> + stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS]
> + stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS]
> + stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> + stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
> +
> + /* Restore original x19 */
> + ldp xzr, x19, [sp], #16
> + ret
> + .endm
> +
> +/*
> + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
> + * struct arm_smccc_1_2_regs *res);
> + */
> +ENTRY(arm_smccc_1_2_smc)
> + SMCCC_1_2 smc
> +ENDPROC(arm_smccc_1_2_smc)
> +
> +#endif
> diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c
> index 22fd541f9a..1bc2d90faa 100644
> --- a/arch/arm/lib/asm-offsets.c
> +++ b/arch/arm/lib/asm-offsets.c
> @@ -9,6 +9,9 @@
>   * generate asm statements containing #defines,
>   * compile this file to assembler, and then extract the
>   * #defines from the assembly-language output.
> + *
> + * (C) Copyright 2022 ARM Limited
> + * Abdellatif El Khlifi 
>   */
>  
>  #include 
> @@ -117,6 +120,17 @@ int main(void)
>   DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2));
>   DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id));
>   DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, 
> state));
> + #ifdef CONFIG_ARM64
> + DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS,  offsetof(struct 
> arm_smccc_1_2_regs, a0));
> + DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS,  offsetof(struct 
> arm_smccc_1_2_regs, a2));
> + DEFINE(ARM_SMCC

Re: [PATCH v5 04/10] arm_ffa: introduce Arm FF-A low-level driver

[Jens Wiklander]

On Mon, Sep 26, 2022 at 03:08:21PM +0100, Abdellatif El Khlifi wrote:
> Add the driver implementing Arm Firmware Framework for Armv8-A v1.0
> 
> The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology.
> 
> This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
> on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
> querying the FF-A framework from the secure world.
> 
> 32-bit version of the ABIs is supported and 64-bit version of FFA_RXTX_MAP
> and FFA_MSG_SEND_DIRECT_{REQ, RESP}.
> 
> In u-boot FF-A design, FF-A is considered as a discoverable bus.
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
> 
> The driver exports its operations to be used by upper layers.
> 
> Exported operations:
> 
> - partition_info_get
> - sync_send_receive
> - rxtx_unmap
> 
> This implementation provides an optional feature to copy the driver data
> to EFI runtime area.
> 
> [1]: https://developer.arm.com/documentation/den0077/latest/
> 
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> ---
> 
> Changelog:
> ===
> 
> v4:
> 
> * add doc/README.ffa.drv
> * moving the FF-A driver work to drivers/firmware/arm-ffa
> * use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
>   #if defined by #if CONFIG_IS_ENABLED
> * improving error handling by mapping the FF-A errors to standard errors
>   and logs
> * replacing panics with an error log and returning an error code
> * improving features discovery in FFA_FEATURES by introducing
>   rxtx_min_pages private data field
> * add ffa_remove and ffa_bind functions
> * improve how the driver behaves when bus discovery is done more than
>   once
> 
> v3:
> 
> * align the interfaces of the u-boot FF-A driver with those in the linux
>   FF-A driver
> * remove the FF-A helper layer
> * make the u-boot FF-A driver independent from EFI
> * provide an optional config that enables copying the driver data to EFI
>   runtime section at ExitBootServices service
> * use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
> 
> v2:
> 
> * make FF-A bus discoverable using device_{bind, probe} APIs
> * remove device tree support
> 
> v1:
> 
> * introduce FF-A bus driver with device tree support
> 
>  MAINTAINERS   |7 +
>  common/board_r.c  |9 +
>  doc/README.ffa.drv|  160 ++
>  drivers/Kconfig   |2 +
>  drivers/Makefile  |1 +
>  drivers/firmware/arm-ffa/Kconfig  |   39 +
>  drivers/firmware/arm-ffa/Makefile |7 +
>  drivers/firmware/arm-ffa/arm-ffa-uclass.c |   16 +
>  drivers/firmware/arm-ffa/arm_ffa_prv.h|  196 +++
>  drivers/firmware/arm-ffa/core.c   | 1344 +
>  .../arm-ffa/efi_ffa_runtime_data_mgr.c|   94 ++
>  include/arm_ffa.h |  127 ++
>  include/dm/uclass-id.h|4 +
>  lib/efi_loader/efi_boottime.c |   15 +
>  14 files changed, 2021 insertions(+)
>  create mode 100644 doc/README.ffa.drv
>  create mode 100644 drivers/firmware/arm-ffa/Kconfig
>  create mode 100644 drivers/firmware/arm-ffa/Makefile
>  create mode 100644 drivers/firmware/arm-ffa/arm-ffa-uclass.c
>  create mode 100644 drivers/firmware/arm-ffa/arm_ffa_prv.h
>  create mode 100644 drivers/firmware/arm-ffa/core.c
>  create mode 100644 drivers/firmware/arm-ffa/efi_ffa_runtime_data_mgr.c
>  create mode 100644 include/arm_ffa.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 83346183ee..02b84d5074 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -248,6 +248,13 @@ F:   drivers/net/cortina_ni.h
>  F:   drivers/net/phy/ca_phy.c
>  F:   configs/cortina_presidio-asic-pnand_defconfig
>  
> +ARM FF-A
> +M:   Abdellatif El Khlifi 
> +S:   Maintained
> +F:   doc/README.ffa.drv
> +F:   drivers/firmware/arm-ffa/
> +F:   include/arm_ffa.h
> +
>  ARM FREESCALE IMX
>  M:   Stefano Babic 
>  M:   Fabio Estevam 
> diff --git a/common/board_r.c b/common/board_r.c
> index 56eb60fa27..8c99faddfd 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -7,6 +7,8 @@
>   * 

Re: [PATCH v5 02/10] arm64: smccc: clear the Xn registers after SMC calls

[Jens Wiklander]

On Mon, Sep 26, 2022 at 03:08:19PM +0100, Abdellatif El Khlifi wrote:
> set to zero the x0-x17 registers
> 
> As per the SMCCC v1.2 spec, unused result and scratch registers
> can leak information after an SMC call. We can mitigate against
> this risk by returning zero in each register.
> 
> The leakage we are referring to is data leakage across exception
> levels. The intent is to prevent lower exception levels (EL1/EL0)
> from reading the SMC data exchanged at EL2.
> 
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> ---
> 
> Changelog:
> ===
> 
> v4:
> 
> * move the clearing code into a new macro: clear_gp_regs
> 
> v3:
> 
> * clear the Xn registers after SMC calls
> 
> 
>  arch/arm/cpu/armv8/smccc-call.S | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index ec6f299bc9..32f3eb8eeb 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -50,6 +50,12 @@ ENDPROC(__arm_smccc_hvc)
>  
>  #ifdef CONFIG_ARM64
>  
> + .macro  clear_gp_regs
> + .irpn,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17
> + mov x\n, xzr
> + .endr
> + .endm
> +
>   .macro SMCCC_1_2 instr
>   /* Save `res` and free a GPR that won't be clobbered */
>   stp x1, x19, [sp, #-16]!
> @@ -84,6 +90,9 @@ ENDPROC(__arm_smccc_hvc)
>   stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
>   stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
>  
> + /* x0-x17 registers can leak information after an SMC or HVC call. 
> Let's clear them */
> + clear_gp_regs
> +

This should in my opinion not be needed. The higher exception level should
only return what it indends to return and certainly not rely on lower
exception levels to try to hide eventual unintentionally revealed
secrets.

In an earlier conversation you said:
> The leakage we are referring to is data leakage across exception levels.
> The intent is to prevent lower exception levels (EL1/EL0) to read the
> data exchanged at EL2.
> 
> The linux kernel clears the general purpose registers before switching
> to EL0. As far as I know u-boot doesn't.
> 
> So, the code above makes sure the registers are cleared.

U-Boot is as far as I know not changing to EL0. Do you have a real example
where this cleaning actually would be needed? If it's needed I'd expect
the cleaning to be done just before changing exception level.

Cheers,
Jens


>   /* Restore original x19 */
>   ldp xzr, x19, [sp], #16
>   ret
> -- 
> 2.17.1
> 

Re: [PATCH v2] tee: optee: rework TA bus scanning code

[Jens Wiklander]

On Fri, Sep 2, 2022 at 9:11 PM Ilias Apalodimas
 wrote:
>
> Thanks Jens
>
> On Wed, 31 Aug 2022 at 08:59, Jens Wiklander  
> wrote:
> >
> > On Mon, Aug 29, 2022 at 8:34 AM Ilias Apalodimas
> >  wrote:
> > >
> > > Late versions of OP-TEE support a pseudo bus.  TAs that behave as
> > > hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we 
> > > can
> > > scan.  Unfortunately U-Boot doesn't support that yet. It's worth noting
> > > that we already have a workaround for RNG.  The details are in
> > > commit 70812bb83da6 ("tee: optee: bind rng optee driver")
> > >
> > > So let's add a list of devices based on U-Boot Kconfig options that we 
> > > will
> > > scan until we properly implement the tee-bus functionality.
> > >
> > > While at it change the behaviour of the tee core itself wrt to device
> > > binding.  If some device binding fails, print a warning instead of
> > > disabling OP-TEE.
> > >
> > > Signed-off-by: Ilias Apalodimas 
> > > ---
> >
> > Reviewed-by: Jens Wiklander 
>
> There's a typo in that patch. For the tpm to work the string needs to
> be ftpm_tee instead of ftpm-tee.  I'll send a v3, shall I keep your
> RB?

Yes, please.

Cheers,
Jens

>
> Cheers
> /Ilias
> >
> > Cheers,
> > Jens
> >
> > > Changes since v1:
> > > - remove a macro and use ARRAY_SIZE directly
> > > - print a warning instead of disabling op-tee if a driver binding fails
> > >
> > >  drivers/tee/optee/core.c | 23 +++
> > >  1 file changed, 19 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > > index a89d62aaf0b3..3cc92f09d299 100644
> > > --- a/drivers/tee/optee/core.c
> > > +++ b/drivers/tee/optee/core.c
> > > @@ -31,6 +31,18 @@ struct optee_pdata {
> > > optee_invoke_fn *invoke_fn;
> > >  };
> > >
> > > +static const struct {
> > > +   const char *drv_name;
> > > +   const char *dev_name;
> > > +} optee_bus_probe[] = {
> > > +#ifdef CONFIG_RNG_OPTEE
> > > +   { "optee-rng", "optee-rng" },
> > > +#endif
> > > +#ifdef CONFIG_TPM2_FTPM_TEE
> > > +   { "ftpm-tee", "ftpm-tee" },
> > > +#endif
> > > +};
> > > +
> > >  struct rpc_param {
> > > u32 a0;
> > > u32 a1;
> > > @@ -643,7 +655,7 @@ static int optee_probe(struct udevice *dev)
> > > struct optee_pdata *pdata = dev_get_plat(dev);
> > > u32 sec_caps;
> > > struct udevice *child;
> > > -   int ret;
> > > +   int ret, i;
> > >
> > > if (!is_optee_api(pdata->invoke_fn)) {
> > > dev_err(dev, "OP-TEE api uid mismatch\n");
> > > @@ -672,10 +684,13 @@ static int optee_probe(struct udevice *dev)
> > >  * in U-Boot, the discovery of TA on the TEE bus is not supported:
> > >  * only bind the drivers associated to the supported OP-TEE TA
> > >  */
> > > -   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> > > -   ret = device_bind_driver(dev, "optee-rng", "optee-rng", 
> > > );
> > > +
> > > +   for (i = 0; i < ARRAY_SIZE(optee_bus_probe); i++) {
> > > +   ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> > > +optee_bus_probe[i].dev_name, 
> > > );
> > > if (ret)
> > > -   return ret;
> > > +   dev_warn(dev, "Failed to bind device %s\n",
> > > +optee_bus_probe[i].dev_name);
> > > }
> > >
> > > return 0;
> > > --
> > > 2.34.1
> > >

Re: [PATCH v2] tee: optee: rework TA bus scanning code

[Jens Wiklander]

On Mon, Aug 29, 2022 at 8:34 AM Ilias Apalodimas
 wrote:
>
> Late versions of OP-TEE support a pseudo bus.  TAs that behave as
> hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we can
> scan.  Unfortunately U-Boot doesn't support that yet. It's worth noting
> that we already have a workaround for RNG.  The details are in
> commit 70812bb83da6 ("tee: optee: bind rng optee driver")
>
> So let's add a list of devices based on U-Boot Kconfig options that we will
> scan until we properly implement the tee-bus functionality.
>
> While at it change the behaviour of the tee core itself wrt to device
> binding.  If some device binding fails, print a warning instead of
> disabling OP-TEE.
>
> Signed-off-by: Ilias Apalodimas 
> ---

Reviewed-by: Jens Wiklander 

Cheers,
Jens

> Changes since v1:
> - remove a macro and use ARRAY_SIZE directly
> - print a warning instead of disabling op-tee if a driver binding fails
>
>  drivers/tee/optee/core.c | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index a89d62aaf0b3..3cc92f09d299 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -31,6 +31,18 @@ struct optee_pdata {
> optee_invoke_fn *invoke_fn;
>  };
>
> +static const struct {
> +   const char *drv_name;
> +   const char *dev_name;
> +} optee_bus_probe[] = {
> +#ifdef CONFIG_RNG_OPTEE
> +   { "optee-rng", "optee-rng" },
> +#endif
> +#ifdef CONFIG_TPM2_FTPM_TEE
> +   { "ftpm-tee", "ftpm-tee" },
> +#endif
> +};
> +
>  struct rpc_param {
> u32 a0;
> u32 a1;
> @@ -643,7 +655,7 @@ static int optee_probe(struct udevice *dev)
> struct optee_pdata *pdata = dev_get_plat(dev);
> u32 sec_caps;
> struct udevice *child;
> -   int ret;
> +   int ret, i;
>
> if (!is_optee_api(pdata->invoke_fn)) {
> dev_err(dev, "OP-TEE api uid mismatch\n");
> @@ -672,10 +684,13 @@ static int optee_probe(struct udevice *dev)
>  * in U-Boot, the discovery of TA on the TEE bus is not supported:
>  * only bind the drivers associated to the supported OP-TEE TA
>  */
> -   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> -   ret = device_bind_driver(dev, "optee-rng", "optee-rng", 
> );
> +
> +   for (i = 0; i < ARRAY_SIZE(optee_bus_probe); i++) {
> +   ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> +optee_bus_probe[i].dev_name, );
> if (ret)
> -   return ret;
> +   dev_warn(dev, "Failed to bind device %s\n",
> +optee_bus_probe[i].dev_name);
> }
>
> return 0;
> --
> 2.34.1
>

Re: [PATCH] tee: optee: rework TA bus scanning code

[Jens Wiklander]

On Tue, Aug 23, 2022 at 10:11 AM Ilias Apalodimas
 wrote:
>
> Late versions of OP-TEE support a pseudo bus.  TAs that behave as
> hardware blocks (e.g TPM, RNG etc) present themselves on a bus which we can
> scan.  Unfortunately U-Boot doesn't support that yet. It's worth noting
> that we already have a workaround for RNG.  The details are in
> commit 70812bb83da6 ("tee: optee: bind rng optee driver")
>
> So let's add a list of devices based on U-Boot Kconfig options that we will
> scan until we properly implement the tee-bus functionality.
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  drivers/tee/optee/core.c | 22 +++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index a89d62aaf0b3..48a9b59171cb 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -31,6 +31,20 @@ struct optee_pdata {
> optee_invoke_fn *invoke_fn;
>  };
>
> +static const struct {
> +   const char *drv_name;
> +   const char *dev_name;
> +} optee_bus_probe[] = {
> +#ifdef CONFIG_RNG_OPTEE
> +   { "optee-rng", "optee-rng" },
> +#endif
> +#ifdef CONFIG_TPM2_FTPM_TEE
> +   { "ftpm-tee", "ftpm-tee" },
> +#endif
> +};
> +
> +#define MAX_TEE_BUS_DEV_COUNT ARRAY_SIZE(optee_bus_probe)
> +
>  struct rpc_param {
> u32 a0;
> u32 a1;
> @@ -643,7 +657,7 @@ static int optee_probe(struct udevice *dev)
> struct optee_pdata *pdata = dev_get_plat(dev);
> u32 sec_caps;
> struct udevice *child;
> -   int ret;
> +   int ret, i;
>
> if (!is_optee_api(pdata->invoke_fn)) {
> dev_err(dev, "OP-TEE api uid mismatch\n");
> @@ -672,8 +686,10 @@ static int optee_probe(struct udevice *dev)
>  * in U-Boot, the discovery of TA on the TEE bus is not supported:
>  * only bind the drivers associated to the supported OP-TEE TA
>  */
> -   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
> -   ret = device_bind_driver(dev, "optee-rng", "optee-rng", 
> );
> +
> +   for (i = 0; i < MAX_TEE_BUS_DEV_COUNT; i++) {
> +   ret = device_bind_driver(dev, optee_bus_probe[i].drv_name,
> +optee_bus_probe[i].dev_name, );
> if (ret)
> return ret;

I wonder which behaviour is most useful. Disable OP-TEE support
completely if there's some error when binding dependent drivers or to
just complain a bit but continue.

Cheers,
Jens


>
> }
> --
> 2.34.1
>

Re: [PATCH v3 2/4] arm64: smccc: clear the Xn registers after SMC calls

[Jens Wiklander]

On Mon, Aug 1, 2022 at 7:21 PM Abdellatif El Khlifi
 wrote:
>
> set to zero the x0-x17 registers
>
> As per the SMCCC v1.2 spec, unused result and scratch registers can leak
> information after an SMC call. We can mitigate against this risk by
> returning zero in each register.
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Ilias Apalodimas 
> Cc: Jens Wiklander 
> ---
>  arch/arm/cpu/armv8/smccc-call.S | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index ec6f299bc9..8ac3e461e4 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -84,6 +84,26 @@ ENDPROC(__arm_smccc_hvc)
> stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS]
> stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS]
>
> +   /* x0-x17 registers can leak information after an SMC or HVC call. 
> Let's clear them */
> +   mov x0, xzr
> +   mov x1, xzr
> +   mov x2, xzr
> +   mov x3, xzr
> +   mov x4, xzr
> +   mov x5, xzr
> +   mov x6, xzr
> +   mov x7, xzr
> +   mov x8, xzr
> +   mov x9, xzr
> +   mov x10, xzr
> +   mov x11, xzr
> +   mov x12, xzr
> +   mov x13, xzr
> +   mov x14, xzr
> +   mov x15, xzr
> +   mov x16, xzr
> +   mov x17, xzr
> +

Is this information leakage worse than the information leakage from an
ordinary C function?
My point is, is this needed?

Thanks,
Jens

> /* Restore original x19 */
> ldp xzr, x19, [sp], #16
> ret
> --
> 2.17.1
>

Re: [PATCH] mach-rockchip: make_fit_atf.py: support OP-TEE tee.bin v1 format

[Jens Wiklander]

Hi,

On Thu, Jun 2, 2022 at 9:50 AM Jerome Forissier
 wrote:
>
>
>
> On 5/29/22 18:08, Alper Nebi Yasak wrote:
> > On 28/05/2022 01:08, Jerome Forissier wrote:
> >> On 5/27/22 21:24, Alper Nebi Yasak wrote:
> >>> On 11/05/2022 18:35, Jerome Forissier wrote:
>  +if paged_sz != 0:
>  +raise ValueError("OP-TEE paged mode not supported")
> >>>
> >>> Is this not feasible/necessary to do, or just not implemented yet?
> >>
> >> Just not implemented yet. Pager support is not strictly needed, its use or 
> >> not
> >> depends on the platform and on the threat model. In other words, whether 
> >> or not
> >> it is OK to have the TEE and TAs run in DRAM, usually isolated only from 
> >> Normal
> >> World software by TrustZone or some kind of memory firewall. Pager allows 
> >> to
> >> protect from physical access to the DRAM too. It provides authentication 
> >> and/or
> >> encryption to anything stored outside the internal SRAM of the SoC.
> >> Testing this mode on RockPi4 would require some non trivial work. Here I 
> >> simply
> >> focused on implementing the current use case properly.
> >
> > I assume you mean it would need platform-specific work on the OP-TEE OS
> > side.
>
> Yes.
>  > But let me ask in a general sense, would we need to pass
> > 'paged_size', 'init_mem_usage', etc. via the FIT to U-Boot? Or, how well
> > does the info in the files and headers (v1 and v2) map to FIT images and
> > their properties?
>
> Yes, the parameters in the tee.bin header would tell U-Boot if the binary 
> needs to
> be split in two parts (paged_size != 0) or not. The load address of the "non 
> paged"
> part is also in the header. And, when a "paged" part is present its load 
> address
> has to be passed to OP-TEE via register x1.
>
> > Why I am asking these is that I'm hypothesizing we can put the
> > unmodified 'tee.bin' (including header) and 'bl31.elf' (normally split
> > into raw binary pieces) into the FIT, and then interpret them at runtime
> > on the C side. Trying to figure out if it's a good idea.
>
> Definitely sounds doable. It could help having more common code perhaps, and 
> also
> simplify the content of the FIT and therefore the verification of hash and
> signatures.
>
>  +e_entry = (start_hi << 32) + start_lo
>  +p_addr = e_entry
>  +p_data = bin[0x1c:]
>  +if len(p_data) != init_sz:
>  +raise ValueError("Invalid file '%s': size mismatch "
>  + "(expected %d, have %d)" % (filename, 
>  init_sz,
>  + len(p_data)))
>  +segments.append((0, e_entry, p_addr, p_data))
>  +else:
>  +raise ValueError("Unknown format for TEE file '%s'" % filename)
> >>>
> >>> I see an 'output_header_v2' in your link [2], what about that?
> >>
> >> v2 is useful only when the OP-TEE pager is used, in which case it is a 
> >> matter
> >> of preference whether to use a single binary and have the loader split it 
> >> as
> >> expected (tee.bin) or use separate binaries instead.
> >>
> >> Historically (Jens please correct me if I'm wrong!), there was a single raw
> >> binary for OP-TEE: tee.bin, and no pager support. Then pager was added. The
> >> build would then create two separate files: tee-pager.bin and 
> >> tee-pageable.bin
> >> (the latter would be zero sized with pager disabled). At the same time a 
> >> header
> >> was introduced in tee.bin to indicate whether or not the file would 
> >> contain a
> >> pageable section (tee.bin consisted in the header + tee-pager.bin +
> >> tee-pageable.bin). Later, and for reasons I don't remember exactly 
> >> (related to
> >> the integration with TF-A IIRC), the header was written to its own file 
> >> and the
> >> format of that header changed a bit. So we had tee-header_v2.bin,
> >> tee-pager_v2.bin, and tee-pageable_v2.bin. The previous tee-pager.bin and
> >> tee-pageable.bin were subsequently deprecated; but tee.bin wasn't. It is 
> >> still
> >> generated today, unchanged with its "v1" header. Note, I'm not sure if
> >> tee-pager_v2.bin is different from tee-pager.bin (and same goes for the
> >> pageable part), but it doesn't really matter for this discussion.
> >
> > Thanks for both explanations. I also kept looking at gen_tee_bin.py and
> >  outputs from a few OP-TEE OS builds. If I got things right, I can do:
> >
> >   cat tee-header_v2.bin tee-pager_v2.bin tee-pageable_v2.bin >tee_v2.bin
> >
> > and that would effectively be the same kind of file/image as tee.bin,
> > just with a v2 header instead of v1, right?
>
> Correct.

It could be worth checking how TF-A loads OP-TEE. The relevant code is
in 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/optee/optee_utils.c

Cheers,
Jens

Re: [PATCH 2/3] imx8m: Automatically add the optee firmware node to the FDT

[Jens Wiklander]

Hi,

On Mon, May 16, 2022 at 12:00 PM Michael Nazzareno Trimarchi
 wrote:
>
> Hi Alban
>
> On Mon, May 16, 2022 at 10:23 AM Alban Bedel  wrote:
> >
> > If optee is running add the firmware node to the FDT to allow the
> > kernel to use a more generic device tree.
> >
> > Signed-off-by: Alban Bedel 
> > ---
> >  arch/arm/mach-imx/imx8m/soc.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> > index 8e23e6da326f..2a78cb6a0952 100644
> > --- a/arch/arm/mach-imx/imx8m/soc.c
> > +++ b/arch/arm/mach-imx/imx8m/soc.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -1347,6 +1348,14 @@ usb_modify_speed:
> >  #endif
> >
> > cleanup_nodes_for_efi(blob);
> > +
> > +   if (rom_pointer[1]) {
> > +   int err = optee_add_firmware_node(blob, "linaro,optee-tz",
> > + "smc");
> > +   if (err)
> > +   return err;
> > +   }
> > +
> > return 0;
> >  }
> >  #endif
> > --
>
> Adding the node is not sufficient. I think that we need reserved
> memory node on top of it. The nice scenario will be
> only to define the size of such area and use always the last part of
> the memory to reserve it. Do you know if we have some api
> to pass information to the atf and optee?

We have an ABI in OP-TEE for this, OPTEE_SMC_GET_SHM_CONFIG. This
function wasn't intended for this, but I can't see that that should be
a problem.

Cheers,
Jens

>
> Michael
> > 2.34.1
>
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> mich...@amarulasolutions.com
> __
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> i...@amarulasolutions.com
> www.amarulasolutions.com

Re: [PATCH v2 1/6] arm_ffa: introduce Arm FF-A low-level driver

[Jens Wiklander]

On Fri, Apr 15, 2022 at 01:27:58PM +0100, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi 
> 
> Add the driver implementing Arm Firmware Framework for Armv8-A v1.0
> 
> The Firmware Framework for Arm A-profile processors (FF-A)
> describes interfaces (ABIs) that standardize communication
> between the Secure World and Normal World leveraging TrustZone
> technology. This driver uses SMC32 calling convention.

How come only the SMC32 calling convention is used? What if you need
64-bit pointers for some reason (RXTX_MAP comes to mind) ? Doing the
64-bit calling convention at the same time can't be much more work.

> 
> In u-boot FF-A design, FF-A is considered as a discoverable bus.
> The Secure World is considered as one entity to communicate with
> using the FF-A bus. FF-A communication is handled by one device and
> one instance (the bus). This FF-A driver takes care of all the
> interactions between Normal world and Secure World.
> 
> The driver provides helper FF-A interfaces for user layers.
> These helper functions allow clients to pass data and select the
> FF-A function to use for the communication with secure world.
> 
> Signed-off-by: Abdellatif El Khlifi 
> ---
>  MAINTAINERS  |8 +
>  arch/arm/cpu/armv8/smccc-call.S  |   27 +
>  arch/arm/lib/asm-offsets.c   |6 +
>  common/board_r.c |7 +
>  drivers/Kconfig  |2 +
>  drivers/Makefile |1 +
>  drivers/arm-ffa/Kconfig  |   27 +
>  drivers/arm-ffa/Makefile |6 +
>  drivers/arm-ffa/arm-ffa-uclass.c |   64 ++
>  drivers/arm-ffa/arm_ffa_prv.h|  193 +
>  drivers/arm-ffa/core.c   | 1349 ++
>  include/arm_ffa.h|  190 +
>  include/arm_ffa_helper.h |   45 +
>  include/dm/uclass-id.h   |1 +
>  include/linux/arm-smccc.h|   28 +-
>  lib/Kconfig  |1 +
>  lib/Makefile |1 +
>  lib/arm-ffa/Kconfig  |6 +
>  lib/arm-ffa/Makefile |8 +
>  lib/arm-ffa/arm_ffa_helper.c |  188 +
>  lib/efi_loader/efi_boottime.c|   17 +
>  21 files changed, 2174 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/arm-ffa/Kconfig
>  create mode 100644 drivers/arm-ffa/Makefile
>  create mode 100644 drivers/arm-ffa/arm-ffa-uclass.c
>  create mode 100644 drivers/arm-ffa/arm_ffa_prv.h
>  create mode 100644 drivers/arm-ffa/core.c
>  create mode 100644 include/arm_ffa.h
>  create mode 100644 include/arm_ffa_helper.h
>  create mode 100644 lib/arm-ffa/Kconfig
>  create mode 100644 lib/arm-ffa/Makefile
>  create mode 100644 lib/arm-ffa/arm_ffa_helper.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aca97cd2a3..efa17206b8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -232,6 +232,14 @@ F:   board/CZ.NIC/
>  F:   configs/turris_*_defconfig
>  F:   include/configs/turris_*.h
>  
> +ARM FF-A
> +M:   Abdellatif El Khlifi 
> +S:   Maintained
> +F:   drivers/arm-ffa/
> +F:   include/arm_ffa.h
> +F:   include/arm_ffa_helper.h
> +F:   lib/arm-ffa/
> +
>  ARM FREESCALE IMX
>  M:   Stefano Babic 
>  M:   Fabio Estevam 
> diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S
> index dc92b28777..9a6aebf194 100644
> --- a/arch/arm/cpu/armv8/smccc-call.S
> +++ b/arch/arm/cpu/armv8/smccc-call.S
> @@ -1,6 +1,8 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  /*
>   * Copyright (c) 2015, Linaro Limited
> + * (C) Copyright 2022 ARM Limited
> + * Abdellatif El Khlifi 
>   */
>  #include 
>  #include 
> @@ -45,3 +47,28 @@ ENDPROC(__arm_smccc_smc)
>  ENTRY(__arm_smccc_hvc)
>   SMCCC   hvc
>  ENDPROC(__arm_smccc_hvc)
> +
> +#if (IS_ENABLED(CONFIG_ARM_FFA_TRANSPORT))
> +
> + .macro FFASMCCC instr
> + .cfi_startproc
> + \instr  #0
> + ldr x9, [sp]
> + stp x0, x1, [x9, #ARM_SMCCC_RES_X0_OFFS]
> + stp x2, x3, [x9, #ARM_SMCCC_RES_X2_OFFS]
> + stp x4, x5, [x9, #ARM_SMCCC_RES_X4_OFFS]
> + stp x6, x7, [x9, #ARM_SMCCC_RES_X6_OFFS]
> + ret
> + .cfi_endproc
> + .endm
> +
> +/*
> + * void arm_ffa_smccc_smc(unsigned long a0, unsigned long a1, unsigned long 
> a2,
> + * unsigned long a3, unsigned long a4, unsigned long a5,
> + * unsigned long a6, unsigned long a7, struct arm_smccc_res *res)
> + */
> +ENTRY(__arm_ffa_smccc_smc)
> + FFASMCCCsmc
> +ENDPROC(__arm_ffa_smccc_smc)
> +
> +#endif
> diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c
> index 22fd541f9a..02a4a42fe6 100644
> --- a/arch/arm/lib/asm-offsets.c
> +++ b/arch/arm/lib/asm-offsets.c
> @@ -9,6 +9,8 @@
>   * generate asm statements containing #defines,
>   * compile this file to assembler, and then extract the
>   * #defines from the assembly-language output.
> + *
> + * (C) Copyright 2022 ARM Limited
>   */
>  
>  #include 
> @@ -115,6 +117,10 @@ int main(void)
>  #ifdef CONFIG_ARM_SMCCC
>   

Re: [PATCH v2] efi_loader: Don't limit the StMM buffer size explicitly

[Jens Wiklander]

Hi Ilias,

On Sat, Dec 25, 2021 at 8:39 PM Ilias Apalodimas
 wrote:
>
> On Sat, Dec 25, 2021 at 05:13:23PM +0100, Heinrich Schuchardt wrote:
> > On 12/25/21 16:04, Ilias Apalodimas wrote:
> > >
> > >
> > > On Sat, 25 Dec 2021, 16:28 Heinrich Schuchardt,  > > > wrote:
> > >
> > >
> > >
> > > Am 25. Dezember 2021 12:16:29 MEZ schrieb Ilias Apalodimas
> > > mailto:ilias.apalodi...@linaro.org>>:
> > >  >> >
> > >  >[...]
> > >  >> >rc = tee_invoke_func(conn.tee, , 2, param);
> > >  >> >tee_shm_free(shm);
> > >  >> > +  /*
> > >  >> > +   * Although the max payload is configurable on StMM, we
> > > only share
> > >  >> > +   * four pages from OP-TEE for the non-secure buffer used to
> > > communicate
> > >  >> > +   * with StMM. OP-TEE will reject anything bigger than that
> > > and will
> > >  >> > +   * return.  So le'ts at least warn users
> > >  >> > +   */
> >
> > The comment mentioning four pages does not make too much sense to me as
> > both OP-TEE as well as U-Boot can be configured to other sizes.
> >
>
> The pages that op-tee uses are not configurable.  What is configurable is
> the number of pages you can request op-tee to map from the non-secure
> world for u-boot sharing.  However the four page restriction I refer to
> is an internal op-tee one and refers to the non-secure world buffer it
> shares with StandAloneMM, not u-boot [1]

The commit message suggests that we may try to use an even larger
buffer if needed. A comment here in the code mentioning how this works
should be useful.

Cheers,
Jens

>
> [...]
>
> [1] 
> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/stmm_sp.c#L73
> Cheers
> /Ilias

Re: [PATCH 3/5] tee: optee: define TEE error code TEE_ERROR_SHORT_BUFFER

[Jens Wiklander]

On Thu, Nov 4, 2021 at 3:15 PM Etienne Carriere
 wrote:
>
> Adds TEE_ERROR_SHORT_BUFFER as TEE error code. This error code is
> commonly used by TEEs to inform caller that the buffer(s) it provided
> is too small for the desired operation.
>
> Cc: Jens Wiklander 
> Signed-off-by: Etienne Carriere 
> ---
>  include/tee.h | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

Re: [PATCH 1/5] tee: define session login identifiers

[Jens Wiklander]

On Thu, Nov 4, 2021 at 3:14 PM Etienne Carriere
 wrote:
>
> Define identifiers for clnt_login field in struct tee_open_session_arg
> based in GlobalPlatform Device TEE IDs and on the REE_KERNEL identifier
> extension from OP-TEE OS.
>
> Cc: Jens Wiklander 
> Signed-off-by: Etienne Carriere 
> ---
> This change was previously discussed in the U-Boot ML, see v2 at:
> https://patchwork.ozlabs.org/project/uboot/patch/20210519142613.7668-1-etienne.carri...@linaro.org/
>
> Changes since this v2 post:
>  - Updated the inline comment describing reserved login Ids
>  - Rephrase 'REE kernel agent' to 'REE kernel/privileged agent' to
>better apply to U-Boot that is not a kernel but still runs at a
>privileged execution level.
> ---
>  include/tee.h | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

Re: [PATCH 2/5] tee: optee: remove unused duplicated login Id macros

[Jens Wiklander]

On Thu, Nov 4, 2021 at 3:15 PM Etienne Carriere
 wrote:
>
> Remove unused OPTEE_MSG_LOGIN_* ID macros as suitable TEE_LOGIN_* ID
> macros are already defined tee.h.
>
> Cc: Jens Wiklander 
> Signed-off-by: Etienne Carriere 
> ---
> This change was previously discussed in the U-Boot ML, latest is
> "[PATCH v2 2/2] tee: optee: support session login as REE kernel", at:
> https://patchwork.ozlabs.org/project/uboot/patch/20210519142613.7668-2-etienne.carri...@linaro.org/
>
> Changes since this v2 post:
>  - Remove sanitation of the login Id passed to OP-TEE as secure world
>  - Rephrase header line since this change now simply remove duplicated
>macros.
>  - Update OPTEE_MSG_CMD_OPEN_SESSION inline description comment with
>a reference to TEE_LOGIN_* macros.
> ---
>  drivers/tee/optee/optee_msg.h | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)

Reviewed-by: Jens Wiklander 

Thanks,
Jens

Re: [PATCH 2/2] tee: add a stub for tee_find_device

[Jens Wiklander]

Hi Patrick,

On Thu, Sep 2, 2021 at 11:56 AM Patrick Delaunay
 wrote:
>
> Add stub for tee_find_device function when CONFIG_TEE is not activated
> to simplify the caller code.
>
> This patch allows to remove the CONFIG_IS_ENABLED(OPTEE) tests
> for stm32 platform.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/fdt.c|  1 -
>  board/st/common/stm32mp_mtdparts.c |  3 +--
>  include/tee.h  | 11 +++
>  3 files changed, 12 insertions(+), 3 deletions(-)

Reviewed-by: Jens Wiklander 

Re: [PATCH v2 2/2] tee: optee: support session login as REE kernel

[Jens Wiklander]

On Wed, May 19, 2021 at 4:27 PM Etienne Carriere
 wrote:
>
> Remove unused OPTEE_MSG_LOGIN_* IDs and rely on the ones introduced in
> tee.h. Change optee core to treat invalid client IDs as public login.
>
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v1:
> - Remove ID conversion. I kept the sanitation of login ID for optee.
> ---
>  drivers/tee/optee/core.c  | 19 ++-
>  drivers/tee/optee/optee_msg.h | 10 --
>  2 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 73dbb22ba0..14f9cce5f8 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -349,6 +349,23 @@ static int optee_close_session(struct udevice *dev, u32 
> session)
> return 0;
>  }
>
> +static u32 optee_login_id(u32 login_id)
> +{
> +   /* Treat invalid IDs as public login */
> +   switch (login_id) {
> +   case TEE_LOGIN_USER:
> +   case TEE_LOGIN_GROUP:
> +   case TEE_LOGIN_APPLICATION:
> +   case TEE_LOGIN_APPLICATION_USER:
> +   case TEE_LOGIN_APPLICATION_GROUP:
> +   case TEE_LOGIN_REE_KERNEL:
> +   return login_id;
> +   case TEE_LOGIN_PUBLIC:
> +   default:
> +   return TEE_LOGIN_PUBLIC;
> +   }
> +}
> +

What is the point with translating an unrecognized value into TEE_LOGIN_PUBLIC?
We could just as well let OP-TEE decide what to do with that.

Cheers,
Jens

Re: [PATCH v2 1/2] tee: define session login identifiers

[Jens Wiklander]

On Wed, May 19, 2021 at 4:27 PM Etienne Carriere
 wrote:
>
> Define identifiers for clnt_login field in struct tee_open_session_arg
> based in GlobalPlatform Device TEE IDs and on the REE_KERNEL identifier
> extension from OP-TEE OS.
>
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v1:
> - Rename macros to TEE_LOGIN_* and use same inline description as made
>   in Linux kernel source tree.
> ---
>  include/tee.h | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/include/tee.h b/include/tee.h
> index 99367b258e..d56530653c 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -31,6 +31,25 @@
>  #define TEE_PARAM_ATTR_MASK(TEE_PARAM_ATTR_TYPE_MASK | \
>  TEE_PARAM_ATTR_META)
>
> +/*
> + * Global Platform login identifiers for tee_open_session_arg::clnt_login
> + */
> +#define TEE_LOGIN_PUBLIC  0x
> +#define TEE_LOGIN_USER0x0001
> +#define TEE_LOGIN_GROUP   0x0002
> +#define TEE_LOGIN_APPLICATION 0x0004
> +#define TEE_LOGIN_APPLICATION_USER0x0005
> +#define TEE_LOGIN_APPLICATION_GROUP   0x0006
> +/*
> + * Disallow user-space to use GP implementation specific login
> + * method range (0x8000 - 0xBFFF). This range is rather
> + * being reserved for REE kernel clients or TEE implementation.
> + */
> +#define TEE_LOGIN_REE_KERNEL_MIN  0x8000
> +#define TEE_LOGIN_REE_KERNEL_MAX  0xBFFF
> +/* Private login method for REE kernel clients */
> +#define TEE_LOGIN_REE_KERNEL  0x8000
> +

I might be a bit odd to talk about user-space in U-Boot, but I suppose
it's still good to know how this is supposed to work later in the
kernel too.

What do others think?

Cheers,
Jens

Re: [PATCH v2] tee: optee: sync cache on pre-reloc OP-TEE invocation

[Jens Wiklander]

On Wed, May 19, 2021 at 4:28 PM Etienne Carriere
 wrote:
>
> This change ensures both U-Boot and OP-TEE see the same content
> from shared memory when OP-TEE is invoked prior U-Boot relocation.
>
> This change is required since U-Boot may execute with data cahce off

cache

> while OP-TEE always enables cache on memory shared with U-Boot.
>
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v1:
> - Fix invocation argument buffer size in optee/core.c, using
>   OPTEE_MSG_GET_ARG_SIZE().
> - add missing #include  in tee-uclass.c
> ---
>  drivers/tee/optee/core.c | 21 -
>  drivers/tee/tee-uclass.c | 19 ++-
>  include/tee.h|  6 ++
>  3 files changed, 44 insertions(+), 2 deletions(-)

With the spell error in the commit message fixed:
Reviewed-by: Jens Wiklander 

Cheers,
Jens

Re: [PATCH] tee: optee: sync cache on pre-reloc OP-TEE invocation

[Jens Wiklander]

On Wed, May 12, 2021 at 5:08 PM Etienne Carriere
 wrote:
>
> This change ensures both U-Boot and OP-TEE see the same content
> from shared memory when OP-TEE is invoked prior U-Boot relocation.
>
> This change is required since U-Boot may execute with data cahce off
> while OP-TEE always enables cache on memory shared with U-Boot.
>
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c | 20 +++-
>  drivers/tee/tee-uclass.c | 18 +-
>  include/tee.h|  6 ++
>  3 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 73dbb22ba0..120d315813 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -1,9 +1,10 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright (c) 2018 Linaro Limited
> + * Copyright (c) 2018-2020 Linaro Limited
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -295,6 +296,15 @@ static u32 call_err_to_res(u32 call_err)
> }
>  }
>
> +static void flush_shm_dcache(struct udevice *dev, struct optee_msg_arg *arg)
> +{
> +   flush_dcache_range(rounddown((ulong)arg, CONFIG_SYS_CACHELINE_SIZE),
> +  roundup((ulong)arg + sizeof(*arg),
> +  CONFIG_SYS_CACHELINE_SIZE));

Please use the OPTEE_MSG_GET_ARG_SIZE() macro to calculate the size of
the argument struct.

Cheers,
Jens

> +
> +   tee_flush_all_shm_dcache(dev);
> +}
> +
>  static u32 do_call_with_arg(struct udevice *dev, struct optee_msg_arg *arg)
>  {
> struct optee_pdata *pdata = dev_get_plat(dev);
> @@ -305,9 +315,17 @@ static u32 do_call_with_arg(struct udevice *dev, struct 
> optee_msg_arg *arg)
> while (true) {
> struct arm_smccc_res res;
>
> +   /* If cache are off from U-Boot, sync the cache shared with 
> OP-TEE */
> +   if (!dcache_status())
> +   flush_shm_dcache(dev, arg);
> +
> pdata->invoke_fn(param.a0, param.a1, param.a2, param.a3,
>  param.a4, param.a5, param.a6, param.a7, 
> );
>
> +   /* If cache are off from U-Boot, sync the cache shared with 
> OP-TEE */
> +   if (!dcache_status())
> +   flush_shm_dcache(dev, arg);
> +
> free(page_list);
> page_list = NULL;
>
> diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
> index 2cc6b6c407..81fcd4e801 100644
> --- a/drivers/tee/tee-uclass.c
> +++ b/drivers/tee/tee-uclass.c
> @@ -1,9 +1,10 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * Copyright (c) 2018 Linaro Limited
> + * Copyright (c) 2018-2020 Linaro Limited
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -233,3 +234,18 @@ void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
> d[7] = s->time_hi_and_version;
> memcpy(d + 8, s->clock_seq_and_node, sizeof(s->clock_seq_and_node));
>  }
> +
> +void tee_flush_all_shm_dcache(struct udevice *dev)
> +{
> +   struct tee_uclass_priv *priv = dev_get_uclass_priv(dev);
> +   struct tee_shm *s;
> +
> +   list_for_each_entry(s, >list_shm, link) {
> +   ulong start = rounddown((ulong)s->addr,
> +   CONFIG_SYS_CACHELINE_SIZE);
> +   ulong end = roundup((ulong)s->addr + s->size,
> +   CONFIG_SYS_CACHELINE_SIZE);
> +
> +   flush_dcache_range(start, end);
> +   }
> +}
> diff --git a/include/tee.h b/include/tee.h
> index 99367b258e..2ef29bfc8f 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -377,4 +377,10 @@ void tee_optee_ta_uuid_from_octets(struct 
> tee_optee_ta_uuid *d,
>  void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
>  const struct tee_optee_ta_uuid *s);
>
> +/**
> + * tee_flush_all_shm_dcache() - Flush data cache for all shared memories
> + * @dev:   The TEE device
> + */
> +void tee_flush_all_shm_dcache(struct udevice *dev);
> +
>  #endif /* __TEE_H */
> --
> 2.17.1
>

Re: [PATCH 2/2] tee: optee: support session login as REE kernel

[Jens Wiklander]

On Wed, May 12, 2021 at 5:06 PM Etienne Carriere
 wrote:
>
> OP-TEE supports an API extension to allow client to open a TEE session
> as REE kernel which OP-TEE uses to differentiate client application
> services from system services that only the REE OS kernel can access.
>
> This change allows U-Boot to invoke OP-TEE which such kernel identity
> and therefore access kernel client specific services.
>
> Signed-off-by: Etienne Carriere 
> ---
>  drivers/tee/optee/core.c  | 24 +++-
>  drivers/tee/optee/optee_msg.h |  2 ++
>  2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 73dbb22ba0..526bf125a0 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -349,6 +349,28 @@ static int optee_close_session(struct udevice *dev, u32 
> session)
> return 0;
>  }
>
> +static uint32_t optee_login_id(enum tee_session_login login)
> +{
> +   /* Treat invalid IDs as public login */
> +   switch (login) {
> +   case TEE_SESSION_LOGIN_USER:
> +   return OPTEE_MSG_LOGIN_USER;
> +   case TEE_SESSION_LOGIN_GROUP:
> +   return OPTEE_MSG_LOGIN_GROUP;
> +   case TEE_SESSION_LOGIN_APPLICATION:
> +   return OPTEE_MSG_LOGIN_APPLICATION;
> +   case TEE_SESSION_LOGIN_APPLICATION_USER:
> +   return OPTEE_MSG_LOGIN_APPLICATION;
> +   case TEE_SESSION_LOGIN_APPLICATION_GROUP:
> +   return OPTEE_MSG_LOGIN_APPLICATION;
> +   case TEE_SESSION_LOGIN_REE_KERNEL:
> +   return OPTEE_MSG_LOGIN_REE_KERNEL;
> +   case TEE_SESSION_LOGIN_PUBLIC:
> +   default:
> +   return OPTEE_MSG_LOGIN_PUBLIC;
> +   }
> +}
> +

I don't see any point in this translation, we could just as well use
the correct values from the start.

Cheers,
Jens

>  static int optee_open_session(struct udevice *dev,
>   struct tee_open_session_arg *arg,
>   uint num_params, struct tee_param *params)
> @@ -372,7 +394,7 @@ static int optee_open_session(struct udevice *dev,
>   OPTEE_MSG_ATTR_META;
> memcpy(_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid));
> memcpy(_arg->params[1].u.value, arg->uuid, 
> sizeof(arg->clnt_uuid));
> -   msg_arg->params[1].u.value.c = arg->clnt_login;
> +   msg_arg->params[1].u.value.c = optee_login_id(arg->clnt_login);
>
> rc = to_msg_param(msg_arg->params + 2, num_params, params);
> if (rc)
> diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
> index 8d40ce60c2..17e8d28e52 100644
> --- a/drivers/tee/optee/optee_msg.h
> +++ b/drivers/tee/optee/optee_msg.h
> @@ -95,6 +95,8 @@
>  #define OPTEE_MSG_LOGIN_APPLICATION0x0004
>  #define OPTEE_MSG_LOGIN_APPLICATION_USER   0x0005
>  #define OPTEE_MSG_LOGIN_APPLICATION_GROUP  0x0006
> +/* OP-TEE extension: log as REE kernel */
> +#define OPTEE_MSG_LOGIN_REE_KERNEL 0x8000
>
>  /*
>   * Page size used in non-contiguous buffer entries
> --
> 2.17.1
>

Re: [PATCH 1/2] tee: define session login identifiers

[Jens Wiklander]

On Wed, May 12, 2021 at 5:06 PM Etienne Carriere
 wrote:
>
> TEE header file defines a clnt_login field in struct tee_open_session_arg
> but does not define the values expected. This change define identifiers
> for the field using a enumerated type. Back end TEE driver is expected to
> convert these IDs into IDs meaningful to the TEE.
>
> Signed-off-by: Etienne Carriere 
> ---
>  include/tee.h | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/include/tee.h b/include/tee.h
> index 99367b258e..b8297601b4 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -31,6 +31,19 @@
>  #define TEE_PARAM_ATTR_MASK(TEE_PARAM_ATTR_TYPE_MASK | \
>  TEE_PARAM_ATTR_META)
>
> +/*
> + * Value for tee_open_session_arg::clnt_login
> + */
> +enum tee_session_login {
> +   TEE_SESSION_LOGIN_PUBLIC = 0,
> +   TEE_SESSION_LOGIN_USER,
> +   TEE_SESSION_LOGIN_GROUP,
> +   TEE_SESSION_LOGIN_APPLICATION,

This is defined as 4 in the spec.

> +   TEE_SESSION_LOGIN_APPLICATION_USER,
> +   TEE_SESSION_LOGIN_APPLICATION_GROUP,

Please make these USER_APPLICATION and GROUP_APPLICATION since that's
the order used in the spec.

> +   TEE_SESSION_LOGIN_REE_KERNEL,

The Linux kernel defines the REE kernel stuff as:
/*
 * Disallow user-space to use GP implementation specific login
 * method range (0x8000 - 0xBFFF). This range is rather
 * being reserved for REE kernel clients or TEE implementation.
 */
#define TEE_IOCTL_LOGIN_REE_KERNEL_MIN  0x8000
#define TEE_IOCTL_LOGIN_REE_KERNEL_MAX  0xBFFF
/* Private login method for REE kernel clients */
#define TEE_IOCTL_LOGIN_REE_KERNEL  0x8000

We should at least try to be in the same implementation defined range.

> +};

I think that using a TEE_LOGIN_ prefix should be enough.

> +
>  /*
>   * Some Global Platform error codes which has a meaning if the
>   * TEE_GEN_CAP_GP bit is returned by the driver in
> @@ -135,8 +148,8 @@ struct tee_param {
>  /**
>   * struct tee_open_session_arg - extra arguments for tee_open_session()
>   * @uuid:  [in] UUID of the Trusted Application
> - * @clnt_uuid: [in] Normally zeroes
> - * @clnt_login:[in] Normally 0
> + * @clnt_uuid: [in] UUID of client, zeroes for PUBLIC/REE_KERNEL
> + * @clnt_login:[in] Class of client TEE_SESSION_LOGIN_*
>   * @session:   [out] Session id
>   * @ret:   [out] return value
>   * @ret_origin:[out] origin of the return value
> @@ -144,7 +157,7 @@ struct tee_param {
>  struct tee_open_session_arg {
> u8 uuid[TEE_UUID_LEN];
> u8 clnt_uuid[TEE_UUID_LEN];
> -   u32 clnt_login;
> +   enum tee_session_login clnt_login;

Please keep this as an u32. It's part of the ABI.

Cheers,
Jens

> u32 session;
> u32 ret;
> u32 ret_origin;
> --
> 2.17.1
>

Re: [RFC PATCH v2 1/2] optee: obtain emmc rpmb info from dt

[Jens Wiklander]

On Mon, Jan 25, 2021 at 12:50 PM Igor Opaniuk  wrote:
>
> Hi Jens,
>
> On Mon, Jan 25, 2021 at 10:50 AM Jens Wiklander
>  wrote:
> >
> > Hi Igor,
> >
> > On Sun, Jan 24, 2021 at 11:39:45AM +0200, Igor Opaniuk wrote:
> > > From: Igor Opaniuk 
> > >
> > > Add support for rpmb-dev property in optee node.
> > > Prioritize that provided eMMC info from DT for RPMB operations over
> > > the one provided by OP-TEE OS core in RPC calls.
> > >
> > > Signed-off-by: Igor Opaniuk 
> > > ---
> > >
> > > Changes in v2:
> > > - Return NULL instead of ERR_PTR(-ENXIO) in get_rpmb_dev in case there
> > >   is no rpmb-dev property or somemithing went wrong
> > >
> > >  drivers/tee/optee/core.c  | 33 +
> > >  drivers/tee/optee/optee_private.h |  2 +-
> > >  drivers/tee/optee/rpmb.c  | 60 ++-
> > >  3 files changed, 70 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > > index b898c32edc..828ab9b00a 100644
> > > --- a/drivers/tee/optee/core.c
> > > +++ b/drivers/tee/optee/core.c
> > > @@ -12,6 +12,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "optee_smc.h"
> > >  #include "optee_msg.h"
> > > @@ -607,14 +608,46 @@ static optee_invoke_fn *get_invoke_func(struct 
> > > udevice *dev)
> > >   return ERR_PTR(-EINVAL);
> > >  }
> > >
> > > +static struct mmc *get_rpmb_dev(struct udevice *dev)
> > > +{
> > > + struct udevice *mmc_dev;
> > > + const fdt32_t *phandle_p;
> > > + u32 phandle;
> > > + int ret = 0;
> > > +
> > > + debug("optee: looking for rpmb device in DT.\n");
> > > +
> > > + phandle_p  = ofnode_get_property(dev_ofnode(dev),
> > > +  "rpmb-dev", NULL);
> > > + if (!phandle_p) {
> > > + debug("optee: missing \"rpmb-dev\" property\n");
> >
> > With this we'll complain in the log each time "rpmb-dev" isn't found
> > even when OP-TEE isn't configured to use RPMB. This might cause some
> > confusion.
>
> Sure I'll wrap with "if (IS_ENABLED(CONFIG_SUPPORT_EMMC_RPMB))"
> get_rpmb_dev() invocation in optee_of_to_plat() .
>
> But as it's just a debug message, I would prefer to keep it for
> debugging purposes
> (I can adjust it, adding the phrase that the driver will use OP-TEE
> provided dev id instead).

Sounds good.

Cheers,
Jens

Re: [RFC PATCH v2 1/2] optee: obtain emmc rpmb info from dt

[Jens Wiklander]

Hi Igor,

On Sun, Jan 24, 2021 at 11:39:45AM +0200, Igor Opaniuk wrote:
> From: Igor Opaniuk 
> 
> Add support for rpmb-dev property in optee node.
> Prioritize that provided eMMC info from DT for RPMB operations over
> the one provided by OP-TEE OS core in RPC calls.
> 
> Signed-off-by: Igor Opaniuk 
> ---
> 
> Changes in v2:
> - Return NULL instead of ERR_PTR(-ENXIO) in get_rpmb_dev in case there
>   is no rpmb-dev property or somemithing went wrong
> 
>  drivers/tee/optee/core.c  | 33 +
>  drivers/tee/optee/optee_private.h |  2 +-
>  drivers/tee/optee/rpmb.c  | 60 ++-
>  3 files changed, 70 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index b898c32edc..828ab9b00a 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "optee_smc.h"
>  #include "optee_msg.h"
> @@ -607,14 +608,46 @@ static optee_invoke_fn *get_invoke_func(struct udevice 
> *dev)
>   return ERR_PTR(-EINVAL);
>  }
>  
> +static struct mmc *get_rpmb_dev(struct udevice *dev)
> +{
> + struct udevice *mmc_dev;
> + const fdt32_t *phandle_p;
> + u32 phandle;
> + int ret = 0;
> +
> + debug("optee: looking for rpmb device in DT.\n");
> +
> + phandle_p  = ofnode_get_property(dev_ofnode(dev),
> +  "rpmb-dev", NULL);
> + if (!phandle_p) {
> + debug("optee: missing \"rpmb-dev\" property\n");

With this we'll complain in the log each time "rpmb-dev" isn't found
even when OP-TEE isn't configured to use RPMB. This might cause some
confusion.

Cheers,
Jens

> + return NULL;
> + }
> +
> + phandle = fdt32_to_cpu(*phandle_p);
> +
> + ret = uclass_get_device_by_phandle_id(UCLASS_MMC, phandle, _dev);
> + if (ret) {
> + printf("optee: invalid phandle value in \"rpmb-dev\".\n");
> + return NULL;
> + }
> +
> + debug("optee: using phandle %d from \"rpmd-dev\" property.\n",
> +   phandle);
> + return mmc_get_mmc_dev(mmc_dev);
> +}
> +
>  static int optee_of_to_plat(struct udevice *dev)
>  {
>   struct optee_pdata *pdata = dev_get_plat(dev);
> + struct optee_private *priv = dev_get_priv(dev);
>  
>   pdata->invoke_fn = get_invoke_func(dev);
>   if (IS_ERR(pdata->invoke_fn))
>   return PTR_ERR(pdata->invoke_fn);
>  
> + priv->rpmb_mmc = get_rpmb_dev(dev);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/tee/optee/optee_private.h 
> b/drivers/tee/optee/optee_private.h
> index 1f07a27ee4..8e5a280622 100644
> --- a/drivers/tee/optee/optee_private.h
> +++ b/drivers/tee/optee/optee_private.h
> @@ -19,8 +19,8 @@
>   */
>  struct optee_private {
>   struct mmc *rpmb_mmc;
> - int rpmb_dev_id;
>   int rpmb_original_part;
> + bool rpmb_inited;
>  };
>  
>  struct optee_msg_arg;
> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> index 0804fc963c..0137c44be1 100644
> --- a/drivers/tee/optee/rpmb.c
> +++ b/drivers/tee/optee/rpmb.c
> @@ -45,55 +45,67 @@ static void release_mmc(struct optee_private *priv)
>  {
>   int rc;
>  
> - if (!priv->rpmb_mmc)
> + if (!priv->rpmb_mmc || !priv->rpmb_inited)
>   return;
>  
> - rc = blk_select_hwpart_devnum(IF_TYPE_MMC, priv->rpmb_dev_id,
> -   priv->rpmb_original_part);
> + rc = mmc_switch_part(priv->rpmb_mmc, priv->rpmb_original_part);
>   if (rc)
>   debug("%s: blk_select_hwpart_devnum() failed: %d\n",
> __func__, rc);
>  
> - priv->rpmb_mmc = NULL;
> + priv->rpmb_inited = false;
> +}
> +
> +static int check_mmc(struct mmc *mmc)
> +{
> + if (!mmc) {
> + debug("Cannot find RPMB device\n");
> + return -ENODEV;
> + }
> + if (!(mmc->version & MMC_VERSION_MMC)) {
> + debug("Device id is not an eMMC device\n");
> + return -ENODEV;
> + }
> + if (mmc->version < MMC_VERSION_4_41) {
> + debug("RPMB is not supported before version 4.41\n");
> + return -ENODEV;
> + }
> +
> + return 0;
>  }
>  
>  static struct mmc *get_mmc(struct optee_private *priv, int dev_id)
>  {
> - struct mmc *mmc;
>   int rc;
>  
> - if (priv->rpmb_mmc && priv->rpmb_dev_id == dev_id)
> + if (priv->rpmb_mmc && priv->rpmb_inited)
>   return priv->rpmb_mmc;
>  
>   release_mmc(priv);
>  
> - mmc = find_mmc_device(dev_id);
> - if (!mmc) {
> - debug("Cannot find RPMB device\n");
> - return NULL;
> - }
> - if (!(mmc->version & MMC_VERSION_MMC)) {
> - debug("Device id %d is not an eMMC device\n", dev_id);
> - return NULL;
> - }
> - if (mmc->version < MMC_VERSION_4_41) {
> - debug("Device id %d: RPMB not supported before version 

Re: [PATCH v6 3/4] drivers: tee: sandbox: add rpc test ta emulation

[Jens Wiklander]

On Fri, Jan 22, 2021 at 12:51 PM Igor Opaniuk  wrote:
>
> From: Igor Opaniuk 
>
> This adds support for RPC test trusted application emulation, which
> permits to test reverse RPC calls to TEE supplicant. Currently it covers
> requests to the I2C bus from TEE.
>
> Signed-off-by: Igor Opaniuk 
> Reviewed-by: Simon Glass 
> ---

Reviewed-by: Jens Wiklander 

Thanks,
Jens

Re: [PATCH] smcc: fix sign bit expansion

[Jens Wiklander]

On Tue, Jan 05, 2021 at 08:03:11PM +, Volodymyr Babchuk wrote:
> Signed ARM_SMCCC_FAST_CALL value is shifted to 31'st bit. Then, it is expanded
> to 64 bit value, which results in 1s in higher 32 bits.
> 
> This causes corrupted values in 64-bit SMC IDs and issues in buggy handlers of
> 32-bit calls.
> 
> We need to make ARM_SMCCC_FAST_CALL unsigned long, so it would work properly
> on 32 bit architectures.
> 
> Signed-off-by: Volodymyr Babchuk 
> ---
>  include/linux/arm-smccc.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Jens Wiklander 

You may want to make the prefix "smccc:" (note the extra c) instead.

Cheers,
Jens

> 
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 2d1e6cc156..7f2be23394 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -11,8 +11,8 @@
>   * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
>   */
>  
> -#define ARM_SMCCC_STD_CALL   0
> -#define ARM_SMCCC_FAST_CALL  1
> +#define ARM_SMCCC_STD_CALL   0UL
> +#define ARM_SMCCC_FAST_CALL  1UL
>  #define ARM_SMCCC_TYPE_SHIFT 31
>  
>  #define ARM_SMCCC_SMC_32 0
> -- 
> 2.29.2

Re: [PATCHv3 3/4] drivers: tee: sandbox: add rpc test ta emulation

[Jens Wiklander]

Hi Igor,

On Wed, Jan 20, 2021 at 11:39:35AM +0200, Igor Opaniuk wrote:
> Hi Jens,
> 
> On Wed, Jan 20, 2021 at 10:49 AM Jens Wiklander
>  wrote:
> >
> > On Tue, Jan 12, 2021 at 09:43:39AM +0100, Jorge Ramirez-Ortiz wrote:
> > > From: Igor Opaniuk 
> > >
> > > This adds support for RPC test trusted application emulation, which
> > > permits to test reverse RPC calls to TEE supplicant. Currently it covers
> > > requests to the I2C bus from TEE.
> > >
> > > Signed-off-by: Igor Opaniuk 
> > > ---
> > >  drivers/tee/Makefile|   2 +
> > >  drivers/tee/optee/Kconfig   |   9 +++
> > >  drivers/tee/sandbox.c   | 137 +++-
> > >  include/tee/optee_ta_rpc_test.h |  28 +++
> > >  4 files changed, 172 insertions(+), 4 deletions(-)
> > >  create mode 100644 include/tee/optee_ta_rpc_test.h
> > >
> > > diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
> > > index 5c8ffdbce8..ff844195ae 100644
> > > --- a/drivers/tee/Makefile
> > > +++ b/drivers/tee/Makefile
> > > @@ -2,5 +2,7 @@
> > >
> > >  obj-y += tee-uclass.o
> > >  obj-$(CONFIG_SANDBOX) += sandbox.o
> > > +obj-$(CONFIG_OPTEE_TA_RPC_TEST) += optee/supplicant.o
> > > +obj-$(CONFIG_OPTEE_TA_RPC_TEST) += optee/i2c.o
> > >  obj-$(CONFIG_OPTEE) += optee/
> > >  obj-y += broadcom/
> > > diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
> > > index d489834df9..65622f30b1 100644
> > > --- a/drivers/tee/optee/Kconfig
> > > +++ b/drivers/tee/optee/Kconfig
> > > @@ -22,6 +22,15 @@ config OPTEE_TA_AVB
> > > The TA can support the "avb" subcommands "read_rb", "write"rb"
> > > and "is_unlocked".
> > >
> > > +config OPTEE_TA_RPC_TEST
> > > + bool "Support RPC TEST TA"
> > > + depends on SANDBOX_TEE
> > > + default y
> > > + help
> > > +   Enables support for RPC test trusted application emulation, which
> > > +   permits to test reverse RPC calls to TEE supplicant. Should
> > > +   be used only in sandbox env.
> > > +
> > >  endmenu
> > >
> > >  endif
> > > diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
> > > index 4b91e7db1b..1cacd443f4 100644
> > > --- a/drivers/tee/sandbox.c
> > > +++ b/drivers/tee/sandbox.c
> > > @@ -7,11 +7,15 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +
> > > +#include "optee/optee_msg.h"
> > > +#include "optee/optee_private.h"
> > >
> > >  /*
> > >   * The sandbox tee driver tries to emulate a generic Trusted Exectution
> > > - * Environment (TEE) with the Trusted Application (TA) OPTEE_TA_AVB
> > > - * available.
> > > + * Environment (TEE) with the Trusted Applications (TA) OPTEE_TA_AVB and
> > > + * OPTEE_TA_RPC_TEST available.
> > >   */
> > >
> > >  static const u32 pstorage_max = 16;
> > > @@ -32,7 +36,32 @@ struct ta_entry {
> > >  struct tee_param *params);
> > >  };
> > >
> > > -#ifdef CONFIG_OPTEE_TA_AVB
> > > +static int get_msg_arg(struct udevice *dev, uint num_params,
> > > +struct tee_shm **shmp, struct optee_msg_arg 
> > > **msg_arg)
> > > +{
> > > + int rc;
> > > + struct optee_msg_arg *ma;
> > > +
> > > + rc = __tee_shm_add(dev, OPTEE_MSG_NONCONTIG_PAGE_SIZE, NULL,
> > > +OPTEE_MSG_GET_ARG_SIZE(num_params), 
> > > TEE_SHM_ALLOC,
> > > +shmp);
> > > + if (rc)
> > > + return rc;
> > > +
> > > + ma = (*shmp)->addr;
> > > + memset(ma, 0, OPTEE_MSG_GET_ARG_SIZE(num_params));
> > > + ma->num_params = num_params;
> > > + *msg_arg = ma;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +inline void *optee_alloc_and_init_page_list(void *buf, ulong len,
> > > +u64 *phys_buf_ptr)
> >
> > Why "inline"?
> That should not be there, will fix in new patch series.
> 
> >
> > > +{
> > > + return 0;
> >
> > How can this work? I'd expect an eventual caller to get a bit
> > di

Re: [PATCHv3 3/4] drivers: tee: sandbox: add rpc test ta emulation

[Jens Wiklander]

On Tue, Jan 12, 2021 at 09:43:39AM +0100, Jorge Ramirez-Ortiz wrote:
> From: Igor Opaniuk 
> 
> This adds support for RPC test trusted application emulation, which
> permits to test reverse RPC calls to TEE supplicant. Currently it covers
> requests to the I2C bus from TEE.
> 
> Signed-off-by: Igor Opaniuk 
> ---
>  drivers/tee/Makefile|   2 +
>  drivers/tee/optee/Kconfig   |   9 +++
>  drivers/tee/sandbox.c   | 137 +++-
>  include/tee/optee_ta_rpc_test.h |  28 +++
>  4 files changed, 172 insertions(+), 4 deletions(-)
>  create mode 100644 include/tee/optee_ta_rpc_test.h
> 
> diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
> index 5c8ffdbce8..ff844195ae 100644
> --- a/drivers/tee/Makefile
> +++ b/drivers/tee/Makefile
> @@ -2,5 +2,7 @@
>  
>  obj-y += tee-uclass.o
>  obj-$(CONFIG_SANDBOX) += sandbox.o
> +obj-$(CONFIG_OPTEE_TA_RPC_TEST) += optee/supplicant.o
> +obj-$(CONFIG_OPTEE_TA_RPC_TEST) += optee/i2c.o
>  obj-$(CONFIG_OPTEE) += optee/
>  obj-y += broadcom/
> diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
> index d489834df9..65622f30b1 100644
> --- a/drivers/tee/optee/Kconfig
> +++ b/drivers/tee/optee/Kconfig
> @@ -22,6 +22,15 @@ config OPTEE_TA_AVB
> The TA can support the "avb" subcommands "read_rb", "write"rb"
> and "is_unlocked".
>  
> +config OPTEE_TA_RPC_TEST
> + bool "Support RPC TEST TA"
> + depends on SANDBOX_TEE
> + default y
> + help
> +   Enables support for RPC test trusted application emulation, which
> +   permits to test reverse RPC calls to TEE supplicant. Should
> +   be used only in sandbox env.
> +
>  endmenu
>  
>  endif
> diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
> index 4b91e7db1b..1cacd443f4 100644
> --- a/drivers/tee/sandbox.c
> +++ b/drivers/tee/sandbox.c
> @@ -7,11 +7,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#include "optee/optee_msg.h"
> +#include "optee/optee_private.h"
>  
>  /*
>   * The sandbox tee driver tries to emulate a generic Trusted Exectution
> - * Environment (TEE) with the Trusted Application (TA) OPTEE_TA_AVB
> - * available.
> + * Environment (TEE) with the Trusted Applications (TA) OPTEE_TA_AVB and
> + * OPTEE_TA_RPC_TEST available.
>   */
>  
>  static const u32 pstorage_max = 16;
> @@ -32,7 +36,32 @@ struct ta_entry {
>  struct tee_param *params);
>  };
>  
> -#ifdef CONFIG_OPTEE_TA_AVB
> +static int get_msg_arg(struct udevice *dev, uint num_params,
> +struct tee_shm **shmp, struct optee_msg_arg **msg_arg)
> +{
> + int rc;
> + struct optee_msg_arg *ma;
> +
> + rc = __tee_shm_add(dev, OPTEE_MSG_NONCONTIG_PAGE_SIZE, NULL,
> +OPTEE_MSG_GET_ARG_SIZE(num_params), TEE_SHM_ALLOC,
> +shmp);
> + if (rc)
> + return rc;
> +
> + ma = (*shmp)->addr;
> + memset(ma, 0, OPTEE_MSG_GET_ARG_SIZE(num_params));
> + ma->num_params = num_params;
> + *msg_arg = ma;
> +
> + return 0;
> +}
> +
> +inline void *optee_alloc_and_init_page_list(void *buf, ulong len,
> +u64 *phys_buf_ptr)

Why "inline"?

> +{
> + return 0;

How can this work? I'd expect an eventual caller to get a bit
disappointed. By the way aren't we usually using NULL for pointers in
U-Boot?

> +}
> +
>  static u32 get_attr(uint n, uint num_params, struct tee_param *params)
>  {
>   if (n >= num_params)
> @@ -63,6 +92,7 @@ bad_params:
>   return TEE_ERROR_BAD_PARAMETERS;
>  }
>  
> +#ifdef CONFIG_OPTEE_TA_AVB
>  static u32 ta_avb_open_session(struct udevice *dev, uint num_params,
>  struct tee_param *params)
>  {
> @@ -214,7 +244,100 @@ static u32 ta_avb_invoke_func(struct udevice *dev, u32 
> func, uint num_params,
>   return TEE_ERROR_NOT_SUPPORTED;
>   }
>  }
> -#endif /*OPTEE_TA_AVB*/
> +#endif /* OPTEE_TA_AVB */
> +
> +#ifdef CONFIG_OPTEE_TA_RPC_TEST
> +static u32 ta_rpc_test_open_session(struct udevice *dev, uint num_params,
> + struct tee_param *params)
> +{
> + /*
> +  * We don't expect additional parameters when opening a session to
> +  * this TA.
> +  */
> + return check_params(TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
> + TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
> + num_params, params);
> +}
> +
> +static void fill_i2c_rpc_params(struct optee_msg_arg *msg_arg, u64 bus_num,
> + u64 chip_addr, u64 op,
> + struct tee_param_memref memref)
> +{
> + msg_arg->params[0].attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT;
> + msg_arg->params[1].attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT;
> + msg_arg->params[2].attr = OPTEE_MSG_ATTR_TYPE_RMEM_INOUT;
> + msg_arg->params[3].attr = OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT;
> +
> + /* trigger I2C 

Re: [PATCH] drivers: tee: i2c trampoline driver

[Jens Wiklander]

Hi Simon,

On Tue, Dec 29, 2020 at 4:32 PM Simon Glass  wrote:
>
> Hi Jorge,
>
> On Mon, 21 Dec 2020 at 11:15, Jorge Ramirez-Ortiz  wrote:
> >
> > This commit gives the secure world access to the I2C bus so it can
> > communicate with I2C slaves (tipically those would be secure elements
> > like the NXP SE050).
> >
>
> Since this code is ported from linux it might be worth adding a link
> to the linux commit or patch.
>
> > Tested on imx8mmevk.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz 
> > ---
> >  drivers/tee/optee/Makefile   |  1 +
> >  drivers/tee/optee/i2c.c  | 88 
> >  drivers/tee/optee/optee_msg.h| 22 ++
> >  drivers/tee/optee/optee_msg_supplicant.h |  5 ++
> >  drivers/tee/optee/optee_private.h| 12 
> >  drivers/tee/optee/supplicant.c   |  3 +
> >  6 files changed, 131 insertions(+)
> >  create mode 100644 drivers/tee/optee/i2c.c
> >
> > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> > index 928d3f8002..068c6e7aa1 100644
> > --- a/drivers/tee/optee/Makefile
> > +++ b/drivers/tee/optee/Makefile
> > @@ -2,4 +2,5 @@
> >
> >  obj-y += core.o
> >  obj-y += supplicant.o
> > +obj-$(CONFIG_DM_I2C) += i2c.o
> >  obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
> > diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> > new file mode 100644
> > index 00..2ebbf1ff7c
> > --- /dev/null
> > +++ b/drivers/tee/optee/i2c.c
> > @@ -0,0 +1,88 @@
> > +// SPDX-License-Identifier: BSD-2-Clause
> > +/*
> > + * Copyright (c) 2020 Foundries.io Ltd
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "optee_msg.h"
> > +#include "optee_private.h"
> > +
> > +static struct {
>
> comments on members, but see below
>
> > +   struct udevice *dev;
> > +   int chip;
> > +   int bus;
> > +} xfer;
>
> How come this is not a local variable? Is it an optimisation? Does it
> make any difference in execution time? If so I think it would be
> better to drop it as state should be kept in driver rmodel. If you
> really want it, then perhaps just keep the dev, since you can use:
>
> dev_seq(dev_get_parent(dev) - to get the bus number the device is on
>
> struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
>
> then use chip->chip_addr to get the chip address
>
> then store 'dev' in priv data in your dev (I think this is struct
> optee_private), the one passed to the function below:
>
> > +
> > +void optee_suppl_cmd_i2c_transfer(struct udevice *dev,
> > + struct optee_msg_arg *arg)
> > +{
> > +   const uint64_t attr[] = {
> > +   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> > +   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> > +   OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
> > +   OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
> > +   };
> > +   struct udevice *chip_dev = NULL;
> > +   struct tee_shm *shm = NULL;
> > +   uint8_t *buf = NULL;
>
> Shouldn't init vars that don't need to be
>
> > +   size_t len = 0;
> > +   int chip = -1;
> > +   int bus = -1;
> > +   int ret = -1;
> > +
> > +   if (arg->num_params != ARRAY_SIZE(attr) ||
> > +   arg->params[0].attr != attr[0] ||
> > +   arg->params[1].attr != attr[1] ||
> > +   arg->params[2].attr != attr[2] ||
> > +   arg->params[3].attr != attr[3]) {
> > +   arg->ret = TEE_ERROR_BAD_PARAMETERS;
> > +   return;
> > +   }
> > +
> > +   len = arg->params[2].u.tmem.size;
> > +   shm = (struct tee_shm *)(unsigned 
> > long)arg->params[2].u.tmem.shm_ref;
> > +   buf = shm->addr;
> > +   if (!buf || !len)
> > +   goto bad;
> > +
> > +   bus = (int)arg->params[0].u.value.b;
> > +   chip = (int)arg->params[0].u.value.c;
> > +
> > +   if (!xfer.dev || xfer.chip != chip || xfer.bus != bus) {
> > +   if (i2c_get_chip_for_busnum(bus, chip, 0, _dev))
> > +   goto bad;
> > +
> > +   xfer.dev = chip_dev;
> > +   xfer.chip = chip;
> > +   xfer.bus = bus;
> > +   }
> > +
> > +   if (arg->params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT)
> > +   if (i2c_set_chip_flags(xfer.dev, DM_I2C_CHIP_10BIT))
> > +   goto bad;
>
> Is this flag defined in the devicetree? If so we could read it in
> i2c_chip_ofdata_to_platdata() (which will be i2c_chip_of_to_plat()
> when the next merge window opens - see upstream/next).
>
> It just seems odd that optee is controlling this, since presumably
> U-Boot knows about it?
>
> > +
> > +   switch (arg->params[0].u.value.a) {
> > +   case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> > +   ret = dm_i2c_read(xfer.dev, 0, buf, len);
> > +   break;
> > +   case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
> > +   ret = dm_i2c_write(xfer.dev, 0, buf, len);
>
> This code should run on sandbox and you 

Re: [PATCH] drivers: tee: i2c trampoline driver

[Jens Wiklander]

On Sun, Dec 27, 2020 at 6:07 PM Jorge Ramirez-Ortiz, Foundries
 wrote:
>
> On 23/12/20, Jens Wiklander wrote:
> > Hi Jorge,
>
> hey
>
> >
> > On Mon, Dec 21, 2020 at 07:15:40PM +0100, Jorge Ramirez-Ortiz wrote:
> > > This commit gives the secure world access to the I2C bus so it can
> > > communicate with I2C slaves (tipically those would be secure elements
> > > like the NXP SE050).
> > >
> > > Tested on imx8mmevk.
> > >
> > > Signed-off-by: Jorge Ramirez-Ortiz 
> > > ---
> > >  drivers/tee/optee/Makefile   |  1 +
> > >  drivers/tee/optee/i2c.c  | 88 
> > >  drivers/tee/optee/optee_msg.h| 22 ++
> > >  drivers/tee/optee/optee_msg_supplicant.h |  5 ++
> > >  drivers/tee/optee/optee_private.h| 12 
> > >  drivers/tee/optee/supplicant.c   |  3 +
> > >  6 files changed, 131 insertions(+)
> > >  create mode 100644 drivers/tee/optee/i2c.c
> > >
> > > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> > > index 928d3f8002..068c6e7aa1 100644
> > > --- a/drivers/tee/optee/Makefile
> > > +++ b/drivers/tee/optee/Makefile
> > > @@ -2,4 +2,5 @@
> > >
> > >  obj-y += core.o
> > >  obj-y += supplicant.o
> > > +obj-$(CONFIG_DM_I2C) += i2c.o
> > >  obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
> > > diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> > > new file mode 100644
> > > index 00..2ebbf1ff7c
> > > --- /dev/null
> > > +++ b/drivers/tee/optee/i2c.c
> > > @@ -0,0 +1,88 @@
> > > +// SPDX-License-Identifier: BSD-2-Clause
> > > +/*
> > > + * Copyright (c) 2020 Foundries.io Ltd
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "optee_msg.h"
> > > +#include "optee_private.h"
> > > +
> > > +static struct {
> > > +   struct udevice *dev;
> > > +   int chip;
> > > +   int bus;
> > > +} xfer;
> > > +
> > > +void optee_suppl_cmd_i2c_transfer(struct udevice *dev,
> > > + struct optee_msg_arg *arg)
> > > +{
> > > +   const uint64_t attr[] = {
> > A u8 instead of uint64_t would give the same result.
>
> ok
>
> >
> > > +   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> > > +   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> > > +   OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
> > > +   OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
> > > +   };
> > > +   struct udevice *chip_dev = NULL;
> > > +   struct tee_shm *shm = NULL;
> > > +   uint8_t *buf = NULL;
> > > +   size_t len = 0;
> > > +   int chip = -1;
> > > +   int bus = -1;
> > > +   int ret = -1;
> > > +
> > > +   if (arg->num_params != ARRAY_SIZE(attr) ||
> > > +   arg->params[0].attr != attr[0] ||
> > > +   arg->params[1].attr != attr[1] ||
> > > +   arg->params[2].attr != attr[2] ||
> > > +   arg->params[3].attr != attr[3]) {
> > > +   arg->ret = TEE_ERROR_BAD_PARAMETERS;
> > > +   return;
> > > +   }
> > > +
> > > +   len = arg->params[2].u.tmem.size;
> > > +   shm = (struct tee_shm *)(unsigned long)arg->params[2].u.tmem.shm_ref;
> > Please replace tmem with rmem. The OPTEE_MSG_ATTR_TYPE_RMEM_INOUT above
> > indicates that we're dealing with a struct optee_msg_param_rmem.
>
> sure, thanks!
>
> >
> > > +   buf = shm->addr;
> > > +   if (!buf || !len)
> > > +   goto bad;
> > > +
> > > +   bus = (int)arg->params[0].u.value.b;
> > > +   chip = (int)arg->params[0].u.value.c;
> > > +
> > > +   if (!xfer.dev || xfer.chip != chip || xfer.bus != bus) {
> > > +   if (i2c_get_chip_for_busnum(bus, chip, 0, _dev))
> > > +   goto bad;
> > > +
> > > +   xfer.dev = chip_dev;
> > > +   xfer.chip = chip;
> > > +   xfer.bus = bus;
> > Is this caching safe? No risk of using stale data?
>
> um no I dont think so - I can't think of a scenario that could cause
> that error, but maybe someone else can comment?
>
> >
> > Thanks,
> > Jens
> >
> > > +   }
> > > +
> > > +   if (arg->params[1].u.v

Re: [PATCH] drivers: tee: i2c trampoline driver

[Jens Wiklander]

Hi Jorge,

On Mon, Dec 21, 2020 at 07:15:40PM +0100, Jorge Ramirez-Ortiz wrote:
> This commit gives the secure world access to the I2C bus so it can
> communicate with I2C slaves (tipically those would be secure elements
> like the NXP SE050).
> 
> Tested on imx8mmevk.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  drivers/tee/optee/Makefile   |  1 +
>  drivers/tee/optee/i2c.c  | 88 
>  drivers/tee/optee/optee_msg.h| 22 ++
>  drivers/tee/optee/optee_msg_supplicant.h |  5 ++
>  drivers/tee/optee/optee_private.h| 12 
>  drivers/tee/optee/supplicant.c   |  3 +
>  6 files changed, 131 insertions(+)
>  create mode 100644 drivers/tee/optee/i2c.c
> 
> diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> index 928d3f8002..068c6e7aa1 100644
> --- a/drivers/tee/optee/Makefile
> +++ b/drivers/tee/optee/Makefile
> @@ -2,4 +2,5 @@
>  
>  obj-y += core.o
>  obj-y += supplicant.o
> +obj-$(CONFIG_DM_I2C) += i2c.o
>  obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
> diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
> new file mode 100644
> index 00..2ebbf1ff7c
> --- /dev/null
> +++ b/drivers/tee/optee/i2c.c
> @@ -0,0 +1,88 @@
> +// SPDX-License-Identifier: BSD-2-Clause
> +/*
> + * Copyright (c) 2020 Foundries.io Ltd
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "optee_msg.h"
> +#include "optee_private.h"
> +
> +static struct {
> + struct udevice *dev;
> + int chip;
> + int bus;
> +} xfer;
> +
> +void optee_suppl_cmd_i2c_transfer(struct udevice *dev,
> +   struct optee_msg_arg *arg)
> +{
> + const uint64_t attr[] = {
A u8 instead of uint64_t would give the same result.

> + OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> + OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
> + OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
> + OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
> + };
> + struct udevice *chip_dev = NULL;
> + struct tee_shm *shm = NULL;
> + uint8_t *buf = NULL;
> + size_t len = 0;
> + int chip = -1;
> + int bus = -1;
> + int ret = -1;
> +
> + if (arg->num_params != ARRAY_SIZE(attr) ||
> + arg->params[0].attr != attr[0] ||
> + arg->params[1].attr != attr[1] ||
> + arg->params[2].attr != attr[2] ||
> + arg->params[3].attr != attr[3]) {
> + arg->ret = TEE_ERROR_BAD_PARAMETERS;
> + return;
> + }
> +
> + len = arg->params[2].u.tmem.size;
> + shm = (struct tee_shm *)(unsigned long)arg->params[2].u.tmem.shm_ref;
Please replace tmem with rmem. The OPTEE_MSG_ATTR_TYPE_RMEM_INOUT above
indicates that we're dealing with a struct optee_msg_param_rmem.

> + buf = shm->addr;
> + if (!buf || !len)
> + goto bad;
> +
> + bus = (int)arg->params[0].u.value.b;
> + chip = (int)arg->params[0].u.value.c;
> +
> + if (!xfer.dev || xfer.chip != chip || xfer.bus != bus) {
> + if (i2c_get_chip_for_busnum(bus, chip, 0, _dev))
> + goto bad;
> +
> + xfer.dev = chip_dev;
> + xfer.chip = chip;
> + xfer.bus = bus;
Is this caching safe? No risk of using stale data?

Thanks,
Jens

> + }
> +
> + if (arg->params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT)
> + if (i2c_set_chip_flags(xfer.dev, DM_I2C_CHIP_10BIT))
> + goto bad;
> +
> + switch (arg->params[0].u.value.a) {
> + case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
> + ret = dm_i2c_read(xfer.dev, 0, buf, len);
> + break;
> + case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
> + ret = dm_i2c_write(xfer.dev, 0, buf, len);
> + break;
> + default:
> + goto bad;
> + }
> +
> + if (ret) {
> + arg->ret = TEE_ERROR_COMMUNICATION;
> + } else {
> + arg->params[3].u.value.a = len;
> + arg->ret = TEE_SUCCESS;
> + }
> +
> + return;
> +bad:
> + arg->ret = TEE_ERROR_BAD_PARAMETERS;
> +}
> diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
> index 24c60960fc..7cedb59a82 100644
> --- a/drivers/tee/optee/optee_msg.h
> +++ b/drivers/tee/optee/optee_msg.h
> @@ -422,4 +422,26 @@ struct optee_msg_arg {
>   */
>  #define OPTEE_MSG_RPC_CMD_SHM_FREE   7
>  
> +/*
> + * Access a device on an i2c bus
> + *
> + * [in]  param[0].u.value.a  mode: RD(0), WR(1)
> + * [in]  param[0].u.value.b  i2c adapter
> + * [in]  param[0].u.value.c  i2c chip
> + *
> + * [in]  param[1].u.value.a  i2c control flags
> + * [in]  param[1].u.value.b  i2c retry (optional)
> + *
> + * [in/out] memref[2]buffer to exchange the transfer 
> data
> + *   with the secure world
> + *
> + * [out]  param[3].u.value.a bytes transferred by the driver
> + */
> +#define 

Re: [PATCH] tee: optee: use dev_info in print_os_revision

[Jens Wiklander]

On Mon, Mar 2, 2020 at 1:22 PM Patrick Delaunay  wrote:
>
> Display TEE version at information level; this patch replaces
> debug() call to dev_info() in print_os_revision() function.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/tee/optee/core.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)

Acked-by: Jens Wiklander 

Cheers,
Jens

Re: [PATCH v2 01/15] dm: fdt: scan for devices under /firmware too

[Jens Wiklander]

Hi Michal,

On Tue, Jan 7, 2020 at 9:49 AM Michal Simek  wrote:
>
> Hi Jens and Simon,
>
> čt 23. 8. 2018 v 12:43 odesílatel Jens Wiklander
>  napsal:
> >
> > Just as /chosen may contain devices /firmware may contain devices, scan
> > for devices under /firmware too.
> >
> > Signed-off-by: Jens Wiklander 
> > ---
> >  drivers/core/root.c | 15 ++-
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/core/root.c b/drivers/core/root.c
> > index 72bcc7d7f2a3..0dca507e1187 100644
> > --- a/drivers/core/root.c
> > +++ b/drivers/core/root.c
> > @@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, 
> > const void *blob,
> > for (offset = fdt_first_subnode(blob, offset);
> >  offset > 0;
> >  offset = fdt_next_subnode(blob, offset)) {
> > -   /* "chosen" node isn't a device itself but may contain 
> > some: */
> > -   if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
> > -   pr_debug("parsing subnodes of \"chosen\"\n");
> > +   const char *node_name = fdt_get_name(blob, offset, NULL);
> > +
> > +   /*
> > +* The "chosen" and "firmware" nodes aren't devices
> > +* themselves but may contain some:
> > +*/
> > +   if (!strcmp(node_name, "chosen") ||
> > +   !strcmp(node_name, "firmware")) {
> > +   pr_debug("parsing subnodes of \"%s\"\n", node_name);
> >
> > err = dm_scan_fdt_node(parent, blob, offset,
> >pre_reloc_only);
> > @@ -286,8 +292,7 @@ static int dm_scan_fdt_node(struct udevice *parent, 
> > const void *blob,
> > err = lists_bind_fdt(parent, offset_to_ofnode(offset), 
> > NULL);
> > if (err && !ret) {
> > ret = err;
> > -   debug("%s: ret=%d\n", fdt_get_name(blob, offset, 
> > NULL),
> > - ret);
> > +   debug("%s: ret=%d\n", node_name, ret);
> > }
> > }
> >
> > --
> > 2.17.1
> >
>
> I have debug issue which I see on ZynqMP that firmware nodes are
> listed in dm tree twice.
> I was caused by this patch.
>
>  firmware  1  [ + ]   zynqmp-firmware   |-- zynqmp-firmware
>  firmware  2  [ + ]   zynqmp-power  |   `-- zynqmp-power
> 
>  firmware  3  [   ]   zynqmp-firmware   `-- zynqmp-firmware
>  firmware  4  [   ]   zynqmp-power  `-- zynqmp-power
>
> On ZynqMP firmware node needs to be populated early that's why
> u-boot,dm-pre-reloc flag is used.
> That's why I am curious how to fix this. Revert this patch or add
> flags to Jens case or do more checking to avoid creating duplicated
> entries of nodes present in firmware node.

Reverting may solve the ZynqMP problem, but it will cause new problems
instead so I'd prefer fixing it properly.
I'm not sure if this is best fixed by more flags or by extra checking
when creating the nodes.

Thanks,
Jens

>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

On Tue, Nov 26, 2019 at 05:19:34PM +0100, Jorge Ramirez-Ortiz wrote:
> The mmc CID value is one of the input parameters used to provision the
> RPMB key. The trusted execution environment expects this value to be
> specified in big endian format.
> 
> Before this fix, on little endian systems, the value returned by the
> linux kernel mmc driver differed from the one returned by u-boot.
> This meant that if linux provisioned the RPMB key, u-boot would not
> have access to the partition (and the other way around).
> 
> Signed-off-by: Jorge Ramirez-Ortiz 

Looks good to me:
Reviewed-by: Jens Wiklander 

Thanks,
Jens

> ---
>  drivers/tee/optee/rpmb.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> index 955155b3f8..cf1ce77e6e 100644
> --- a/drivers/tee/optee/rpmb.c
> +++ b/drivers/tee/optee/rpmb.c
> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct optee_private *priv, int 
> dev_id)
>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info *info)
>  {
>   struct mmc *mmc = find_mmc_device(dev_id);
> + int i;
>  
>   if (!mmc)
>   return TEE_ERROR_ITEM_NOT_FOUND;
> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, struct 
> rpmb_dev_info *info)
>   if (!mmc->ext_csd)
>   return TEE_ERROR_GENERIC;
>  
> - memcpy(info->cid, mmc->cid, sizeof(info->cid));
> + for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> + ((u32 *) info->cid)[i] = cpu_to_be32(mmc->cid[i]);
> +
>   info->rel_wr_sec_c = mmc->ext_csd[222];
>   info->rpmb_size_mult = mmc->ext_csd[168];
>   info->ret_code = RPMB_CMD_GET_DEV_INFO_RET_OK;
> -- 
> 2.17.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

On Tue, Nov 26, 2019 at 09:22:38AM +0100, Jorge Ramirez-Ortiz, Foundries wrote:
> On 20/11/19 11:33:10, Jens Wiklander wrote:
> > On Wed, Nov 20, 2019 at 09:21:35AM +0100, Jorge Ramirez-Ortiz wrote:
> > > On 11/20/19 8:20 AM, Jens Wiklander wrote:
> > > > On Tue, Nov 19, 2019 at 06:21:34PM +0100, Jorge Ramirez-Ortiz wrote:
> > > >> On 11/19/19 12:53 PM, Jorge Ramirez-Ortiz wrote:
> > > >>> On 11/19/19 10:02 AM, Jens Wiklander wrote:
> > > >>>> On Mon, Nov 18, 2019 at 02:18:55PM +0100, Jorge Ramirez-Ortiz wrote:
> > > >>>>> On 11/18/19 1:42 PM, Jens Wiklander wrote:
> > > >>>>>> [+ Igor and Sam]
> > > >>>>>>
> > > >>>>>> On Mon, Nov 18, 2019 at 12:18:27PM +0100, Jorge Ramirez-Ortiz 
> > > >>>>>> wrote:
> > > >>>>>>> On 11/18/19 10:36 AM, Jens Wiklander wrote:
> > > >>>>>>>> Hi Jorge,
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> hey!
> > > >>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Fri, Nov 15, 2019 at 10:37 PM Jorge Ramirez-Ortiz 
> > > >>>>>>>>  wrote:
> > > >>>>>>>>> The MMC CID value is one of the input parameters to 
> > > >>>>>>>>> unequivocally
> > > >>>>>>>>> provision the the RPMB key.
> > > >>>>>>>>>
> > > >>>>>>>>> Before this patch, the value returned by the mmc driver in the 
> > > >>>>>>>>> Linux
> > > >>>>>>>>> kernel differs from the one returned by uboot to optee.
> > > >>>>>>>>>
> > > >>>>>>>>> This means that if Linux provisions the RPMB key, uboot wont be 
> > > >>>>>>>>> able
> > > >>>>>>>>> to access it (and the other way around).
> > > >>>>>>>>>
> > > >>>>>>>>> Fix it so both uboot and linux can access the RPMB partition
> > > >>>>>>>>> independently of who provisions the key.
> > > >>>>>>>>>
> > > >>>>>>>>> Signed-off-by: Jorge Ramirez-Ortiz 
> > > >>>>>>>>> ---
> > > >>>>>>>>>  drivers/tee/optee/rpmb.c | 5 -
> > > >>>>>>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >>>>>>>>>
> > > >>>>>>>>> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> > > >>>>>>>>> index 955155b3f8..5dbb1eae4a 100644
> > > >>>>>>>>> --- a/drivers/tee/optee/rpmb.c
> > > >>>>>>>>> +++ b/drivers/tee/optee/rpmb.c
> > > >>>>>>>>> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct 
> > > >>>>>>>>> optee_private *priv, int dev_id)
> > > >>>>>>>>>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info 
> > > >>>>>>>>> *info)
> > > >>>>>>>>>  {
> > > >>>>>>>>> struct mmc *mmc = find_mmc_device(dev_id);
> > > >>>>>>>>> +   int i;
> > > >>>>>>>>>
> > > >>>>>>>>> if (!mmc)
> > > >>>>>>>>> return TEE_ERROR_ITEM_NOT_FOUND;
> > > >>>>>>>>> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, 
> > > >>>>>>>>> struct rpmb_dev_info *info)
> > > >>>>>>>>> if (!mmc->ext_csd)
> > > >>>>>>>>> return TEE_ERROR_GENERIC;
> > > >>>>>>>>>
> > > >>>>>>>>> -   memcpy(info->cid, mmc->cid, sizeof(info->cid));
> > > >>>>>>>>> +   for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> > > >>>>>>>>> +   ((u32 *) info->cid)[i] = 
> >

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

On Wed, Nov 20, 2019 at 09:21:35AM +0100, Jorge Ramirez-Ortiz wrote:
> On 11/20/19 8:20 AM, Jens Wiklander wrote:
> > On Tue, Nov 19, 2019 at 06:21:34PM +0100, Jorge Ramirez-Ortiz wrote:
> >> On 11/19/19 12:53 PM, Jorge Ramirez-Ortiz wrote:
> >>> On 11/19/19 10:02 AM, Jens Wiklander wrote:
> >>>> On Mon, Nov 18, 2019 at 02:18:55PM +0100, Jorge Ramirez-Ortiz wrote:
> >>>>> On 11/18/19 1:42 PM, Jens Wiklander wrote:
> >>>>>> [+ Igor and Sam]
> >>>>>>
> >>>>>> On Mon, Nov 18, 2019 at 12:18:27PM +0100, Jorge Ramirez-Ortiz wrote:
> >>>>>>> On 11/18/19 10:36 AM, Jens Wiklander wrote:
> >>>>>>>> Hi Jorge,
> >>>>>>>
> >>>>>>>
> >>>>>>> hey!
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Nov 15, 2019 at 10:37 PM Jorge Ramirez-Ortiz 
> >>>>>>>>  wrote:
> >>>>>>>>> The MMC CID value is one of the input parameters to unequivocally
> >>>>>>>>> provision the the RPMB key.
> >>>>>>>>>
> >>>>>>>>> Before this patch, the value returned by the mmc driver in the Linux
> >>>>>>>>> kernel differs from the one returned by uboot to optee.
> >>>>>>>>>
> >>>>>>>>> This means that if Linux provisions the RPMB key, uboot wont be able
> >>>>>>>>> to access it (and the other way around).
> >>>>>>>>>
> >>>>>>>>> Fix it so both uboot and linux can access the RPMB partition
> >>>>>>>>> independently of who provisions the key.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Jorge Ramirez-Ortiz 
> >>>>>>>>> ---
> >>>>>>>>>  drivers/tee/optee/rpmb.c | 5 -
> >>>>>>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> >>>>>>>>> index 955155b3f8..5dbb1eae4a 100644
> >>>>>>>>> --- a/drivers/tee/optee/rpmb.c
> >>>>>>>>> +++ b/drivers/tee/optee/rpmb.c
> >>>>>>>>> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct optee_private 
> >>>>>>>>> *priv, int dev_id)
> >>>>>>>>>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info 
> >>>>>>>>> *info)
> >>>>>>>>>  {
> >>>>>>>>> struct mmc *mmc = find_mmc_device(dev_id);
> >>>>>>>>> +   int i;
> >>>>>>>>>
> >>>>>>>>> if (!mmc)
> >>>>>>>>> return TEE_ERROR_ITEM_NOT_FOUND;
> >>>>>>>>> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, struct 
> >>>>>>>>> rpmb_dev_info *info)
> >>>>>>>>> if (!mmc->ext_csd)
> >>>>>>>>> return TEE_ERROR_GENERIC;
> >>>>>>>>>
> >>>>>>>>> -   memcpy(info->cid, mmc->cid, sizeof(info->cid));
> >>>>>>>>> +   for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> >>>>>>>>> +   ((u32 *) info->cid)[i] = be32_to_cpu(mmc->cid[i]);
> >>>>>>>>> +
> >>>>>>>> So it seems to be a byte order issue. I can't find the place in the
> >>>>>>>> Linux kernel (or in tee-supplicant) where the corresponding byte
> >>>>>>>> swapping is done. Have you been able to find it or you just tried to
> >>>>>>>> swap the bytes and it seemed to work?
> >>>>>>>
> >>>>>>>
> >>>>>>> I compared against the full CID output from Linux and noticed that in
> >>>>>>> order to match that exact same output this swap seemed to be 
> >>>>>>> required. I
> >>>>>>> didnt dig any deeper since a similar swap operation is done on other
> >>>>>>> -diff

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

On Tue, Nov 19, 2019 at 06:21:34PM +0100, Jorge Ramirez-Ortiz wrote:
> On 11/19/19 12:53 PM, Jorge Ramirez-Ortiz wrote:
> > On 11/19/19 10:02 AM, Jens Wiklander wrote:
> >> On Mon, Nov 18, 2019 at 02:18:55PM +0100, Jorge Ramirez-Ortiz wrote:
> >>> On 11/18/19 1:42 PM, Jens Wiklander wrote:
> >>>> [+ Igor and Sam]
> >>>>
> >>>> On Mon, Nov 18, 2019 at 12:18:27PM +0100, Jorge Ramirez-Ortiz wrote:
> >>>>> On 11/18/19 10:36 AM, Jens Wiklander wrote:
> >>>>>> Hi Jorge,
> >>>>>
> >>>>>
> >>>>> hey!
> >>>>>
> >>>>>>
> >>>>>> On Fri, Nov 15, 2019 at 10:37 PM Jorge Ramirez-Ortiz 
> >>>>>>  wrote:
> >>>>>>> The MMC CID value is one of the input parameters to unequivocally
> >>>>>>> provision the the RPMB key.
> >>>>>>>
> >>>>>>> Before this patch, the value returned by the mmc driver in the Linux
> >>>>>>> kernel differs from the one returned by uboot to optee.
> >>>>>>>
> >>>>>>> This means that if Linux provisions the RPMB key, uboot wont be able
> >>>>>>> to access it (and the other way around).
> >>>>>>>
> >>>>>>> Fix it so both uboot and linux can access the RPMB partition
> >>>>>>> independently of who provisions the key.
> >>>>>>>
> >>>>>>> Signed-off-by: Jorge Ramirez-Ortiz 
> >>>>>>> ---
> >>>>>>>  drivers/tee/optee/rpmb.c | 5 -
> >>>>>>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> >>>>>>> index 955155b3f8..5dbb1eae4a 100644
> >>>>>>> --- a/drivers/tee/optee/rpmb.c
> >>>>>>> +++ b/drivers/tee/optee/rpmb.c
> >>>>>>> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct optee_private 
> >>>>>>> *priv, int dev_id)
> >>>>>>>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info *info)
> >>>>>>>  {
> >>>>>>> struct mmc *mmc = find_mmc_device(dev_id);
> >>>>>>> +   int i;
> >>>>>>>
> >>>>>>> if (!mmc)
> >>>>>>> return TEE_ERROR_ITEM_NOT_FOUND;
> >>>>>>> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, struct 
> >>>>>>> rpmb_dev_info *info)
> >>>>>>> if (!mmc->ext_csd)
> >>>>>>> return TEE_ERROR_GENERIC;
> >>>>>>>
> >>>>>>> -   memcpy(info->cid, mmc->cid, sizeof(info->cid));
> >>>>>>> +   for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> >>>>>>> +   ((u32 *) info->cid)[i] = be32_to_cpu(mmc->cid[i]);
> >>>>>>> +
> >>>>>> So it seems to be a byte order issue. I can't find the place in the
> >>>>>> Linux kernel (or in tee-supplicant) where the corresponding byte
> >>>>>> swapping is done. Have you been able to find it or you just tried to
> >>>>>> swap the bytes and it seemed to work?
> >>>>>
> >>>>>
> >>>>> I compared against the full CID output from Linux and noticed that in
> >>>>> order to match that exact same output this swap seemed to be required. I
> >>>>> didnt dig any deeper since a similar swap operation is done on other
> >>>>> -different - values returned from U-boot to OP-TEE.
> >>>>
> >>>> So we don't know if the byte swap is always needed, only on little
> >>>> endian machines or perhaps only with certain devices.
> >>>
> >>> right, I dont know.
> >>>>
> >>>> By the way, where are the other byte swaps you're mentioning? I did a
> >>>> quick grep under drivers/tee/ and didn't find anything.
> >>>
> >>> um my bad...let me clarify: when I was hacking around the issues I had
> >>> with the rpmb uboot driver, I was merging/testing some of the code from
> >>> the emulation mode in t

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

On Mon, Nov 18, 2019 at 02:18:55PM +0100, Jorge Ramirez-Ortiz wrote:
> On 11/18/19 1:42 PM, Jens Wiklander wrote:
> > [+ Igor and Sam]
> > 
> > On Mon, Nov 18, 2019 at 12:18:27PM +0100, Jorge Ramirez-Ortiz wrote:
> >> On 11/18/19 10:36 AM, Jens Wiklander wrote:
> >>> Hi Jorge,
> >>
> >>
> >> hey!
> >>
> >>>
> >>> On Fri, Nov 15, 2019 at 10:37 PM Jorge Ramirez-Ortiz  
> >>> wrote:
> >>>> The MMC CID value is one of the input parameters to unequivocally
> >>>> provision the the RPMB key.
> >>>>
> >>>> Before this patch, the value returned by the mmc driver in the Linux
> >>>> kernel differs from the one returned by uboot to optee.
> >>>>
> >>>> This means that if Linux provisions the RPMB key, uboot wont be able
> >>>> to access it (and the other way around).
> >>>>
> >>>> Fix it so both uboot and linux can access the RPMB partition
> >>>> independently of who provisions the key.
> >>>>
> >>>> Signed-off-by: Jorge Ramirez-Ortiz 
> >>>> ---
> >>>>  drivers/tee/optee/rpmb.c | 5 -
> >>>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> >>>> index 955155b3f8..5dbb1eae4a 100644
> >>>> --- a/drivers/tee/optee/rpmb.c
> >>>> +++ b/drivers/tee/optee/rpmb.c
> >>>> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct optee_private *priv, 
> >>>> int dev_id)
> >>>>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info *info)
> >>>>  {
> >>>> struct mmc *mmc = find_mmc_device(dev_id);
> >>>> +   int i;
> >>>>
> >>>> if (!mmc)
> >>>> return TEE_ERROR_ITEM_NOT_FOUND;
> >>>> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, struct 
> >>>> rpmb_dev_info *info)
> >>>> if (!mmc->ext_csd)
> >>>> return TEE_ERROR_GENERIC;
> >>>>
> >>>> -   memcpy(info->cid, mmc->cid, sizeof(info->cid));
> >>>> +   for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> >>>> +   ((u32 *) info->cid)[i] = be32_to_cpu(mmc->cid[i]);
> >>>> +
> >>> So it seems to be a byte order issue. I can't find the place in the
> >>> Linux kernel (or in tee-supplicant) where the corresponding byte
> >>> swapping is done. Have you been able to find it or you just tried to
> >>> swap the bytes and it seemed to work?
> >>
> >>
> >> I compared against the full CID output from Linux and noticed that in
> >> order to match that exact same output this swap seemed to be required. I
> >> didnt dig any deeper since a similar swap operation is done on other
> >> -different - values returned from U-boot to OP-TEE.
> > 
> > So we don't know if the byte swap is always needed, only on little
> > endian machines or perhaps only with certain devices.
> 
> right, I dont know.
> > 
> > By the way, where are the other byte swaps you're mentioning? I did a
> > quick grep under drivers/tee/ and didn't find anything.
> 
> um my bad...let me clarify: when I was hacking around the issues I had
> with the rpmb uboot driver, I was merging/testing some of the code from
> the emulation mode in the linux tee-supplicant (rpbm values are
> converted to network byte order); doing so allowed me to moved through
> the response validation stage in optee so I figured that CID probably
> was missing some sort of conversion as well.
> 
> 
> > 
> >>
> >>
> >>>
> >>> I'm not yet convinced that be32_to_cpu() is the correct function here.
> >>> OP-TEE masks out a few fields from the CID when deriving the key:
> >>
> >>
> >> sure but isnt that a different matter?
> > 
> > No, it's important that OP-TEE masks out the correct fields. That's why
> > we must make sure to understand the problem so we don't just push the
> > problem around.
> 
> ok.
> if there is anything you'd like me to test or validate please let me know

I'm not convinced that this is a generic problem. I don't doubt that
it's a problem on the hardware you're using. Perhaps there's some
byteswap missing in the driver for you hardware. So if you could figure
out why the CID is

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

[+ Igor and Sam]

On Mon, Nov 18, 2019 at 12:18:27PM +0100, Jorge Ramirez-Ortiz wrote:
> On 11/18/19 10:36 AM, Jens Wiklander wrote:
> > Hi Jorge,
> 
> 
> hey!
> 
> >
> > On Fri, Nov 15, 2019 at 10:37 PM Jorge Ramirez-Ortiz  
> > wrote:
> >> The MMC CID value is one of the input parameters to unequivocally
> >> provision the the RPMB key.
> >>
> >> Before this patch, the value returned by the mmc driver in the Linux
> >> kernel differs from the one returned by uboot to optee.
> >>
> >> This means that if Linux provisions the RPMB key, uboot wont be able
> >> to access it (and the other way around).
> >>
> >> Fix it so both uboot and linux can access the RPMB partition
> >> independently of who provisions the key.
> >>
> >> Signed-off-by: Jorge Ramirez-Ortiz 
> >> ---
> >>  drivers/tee/optee/rpmb.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> >> index 955155b3f8..5dbb1eae4a 100644
> >> --- a/drivers/tee/optee/rpmb.c
> >> +++ b/drivers/tee/optee/rpmb.c
> >> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct optee_private *priv, 
> >> int dev_id)
> >>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info *info)
> >>  {
> >> struct mmc *mmc = find_mmc_device(dev_id);
> >> +   int i;
> >>
> >> if (!mmc)
> >> return TEE_ERROR_ITEM_NOT_FOUND;
> >> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, struct 
> >> rpmb_dev_info *info)
> >> if (!mmc->ext_csd)
> >> return TEE_ERROR_GENERIC;
> >>
> >> -   memcpy(info->cid, mmc->cid, sizeof(info->cid));
> >> +   for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> >> +   ((u32 *) info->cid)[i] = be32_to_cpu(mmc->cid[i]);
> >> +
> > So it seems to be a byte order issue. I can't find the place in the
> > Linux kernel (or in tee-supplicant) where the corresponding byte
> > swapping is done. Have you been able to find it or you just tried to
> > swap the bytes and it seemed to work?
> 
> 
> I compared against the full CID output from Linux and noticed that in
> order to match that exact same output this swap seemed to be required. I
> didnt dig any deeper since a similar swap operation is done on other
> -different - values returned from U-boot to OP-TEE.

So we don't know if the byte swap is always needed, only on little
endian machines or perhaps only with certain devices.

By the way, where are the other byte swaps you're mentioning? I did a
quick grep under drivers/tee/ and didn't find anything.

> 
> 
> >
> > I'm not yet convinced that be32_to_cpu() is the correct function here.
> > OP-TEE masks out a few fields from the CID when deriving the key:
> 
> 
> sure but isnt that a different matter?

No, it's important that OP-TEE masks out the correct fields. That's why
we must make sure to understand the problem so we don't just push the
problem around.

> 
> AFAICS U-boot should be providing the same CID than Linux does, and
> whatever OP-TEE might be masking out on the receiving end is orthogonal
> to such value, isnt it? maybe I am not understanding your point?

I agree that something must be done so it works with Linux. However, I'm
a bit surprised that we haven't seen this earlier.

If there's an error in how it's done in Linux we may need to implement
some workaround in tee-supplicant or perhaps in secure world. If we wait
with that until after we have some workarounds in U-Boot too, stuff will
become even more messy.

Cheers,
Jens

> 
> 
> >
> > CID is a uint8_t[16] here
> > /*
> >  * PRV/CRC would be changed when doing eMMC FFU
> >  * The following fields should be masked off when deriving RPMB key
> >  *
> >  * CID [55: 48]: PRV (Product revision)
> >  * CID [07: 01]: CRC (CRC7 checksum)
> >  * CID [00]: not used
> >  */
> >
> > Will this work as expected on a big endian machine?
> >
> > Cheers,
> > Jens
> >
> >> info->rel_wr_sec_c = mmc->ext_csd[222];
> >> info->rpmb_size_mult = mmc->ext_csd[168];
> >> info->ret_code = RPMB_CMD_GET_DEV_INFO_RET_OK;
> >> --
> >> 2.23.0
> >>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: optee: rpmb: fix returning CID to TEE

[Jens Wiklander]

Hi Jorge,

On Fri, Nov 15, 2019 at 10:37 PM Jorge Ramirez-Ortiz  wrote:
>
> The MMC CID value is one of the input parameters to unequivocally
> provision the the RPMB key.
>
> Before this patch, the value returned by the mmc driver in the Linux
> kernel differs from the one returned by uboot to optee.
>
> This means that if Linux provisions the RPMB key, uboot wont be able
> to access it (and the other way around).
>
> Fix it so both uboot and linux can access the RPMB partition
> independently of who provisions the key.
>
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  drivers/tee/optee/rpmb.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> index 955155b3f8..5dbb1eae4a 100644
> --- a/drivers/tee/optee/rpmb.c
> +++ b/drivers/tee/optee/rpmb.c
> @@ -98,6 +98,7 @@ static struct mmc *get_mmc(struct optee_private *priv, int 
> dev_id)
>  static u32 rpmb_get_dev_info(u16 dev_id, struct rpmb_dev_info *info)
>  {
> struct mmc *mmc = find_mmc_device(dev_id);
> +   int i;
>
> if (!mmc)
> return TEE_ERROR_ITEM_NOT_FOUND;
> @@ -105,7 +106,9 @@ static u32 rpmb_get_dev_info(u16 dev_id, struct 
> rpmb_dev_info *info)
> if (!mmc->ext_csd)
> return TEE_ERROR_GENERIC;
>
> -   memcpy(info->cid, mmc->cid, sizeof(info->cid));
> +   for (i = 0; i < ARRAY_SIZE(mmc->cid); i++)
> +   ((u32 *) info->cid)[i] = be32_to_cpu(mmc->cid[i]);
> +

So it seems to be a byte order issue. I can't find the place in the
Linux kernel (or in tee-supplicant) where the corresponding byte
swapping is done. Have you been able to find it or you just tried to
swap the bytes and it seemed to work?

I'm not yet convinced that be32_to_cpu() is the correct function here.
OP-TEE masks out a few fields from the CID when deriving the key:

CID is a uint8_t[16] here
/*
 * PRV/CRC would be changed when doing eMMC FFU
 * The following fields should be masked off when deriving RPMB key
 *
 * CID [55: 48]: PRV (Product revision)
 * CID [07: 01]: CRC (CRC7 checksum)
 * CID [00]: not used
 */

Will this work as expected on a big endian machine?

Cheers,
Jens

> info->rel_wr_sec_c = mmc->ext_csd[222];
> info->rpmb_size_mult = mmc->ext_csd[168];
> info->ret_code = RPMB_CMD_GET_DEV_INFO_RET_OK;
> --
> 2.23.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] image: fdt: copy possible optee nodes to a loaded devicetree

[Jens Wiklander]

On Tue, Oct 22, 2019 at 09:04:27PM +0200, Heiko Stuebner wrote:
> From: Heiko Stuebner 
> 
> The loading convention for optee or any other tee on arm64 is as bl32
> parameter to the trusted-firmware. So TF-A gets invoked with the TEE as
> bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps
> into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33.
> 
> All of them get passed a devicetree as parameter and all components often
> get loaded from a FIT image.
> 
> OP-TEE will create additional nodes in that devicetree namely a firmware
> node and possibly multiple reserved-memory nodes.
> 
> While this devicetree is used in main u-boot, in most cases it won't be
> the one passed to the actual kernel. Instead most boot commands will load
> a new devicetree from somewhere like mass storage of the network, so if
> that happens u-boot should transfer the optee nodes to that new devicetree.
> 
> To make that happen introduce optee_copy_fdt_nodes() called from the dt
> setup function in image-fdt which after checking for the optee presence
> in the u-boot dt will make sure a optee node is present in the kernel dt
> and transfer any reserved-memory regions it can find.
> 
> Signed-off-by: Heiko Stuebner 
> ---
> changes in v2:
> - don't create a new optee firmware-node, but instead copy the
>   compatible+method properties from the old fdt blob.
> 
>  common/image-fdt.c  |   8 +++
>  include/tee/optee.h |   9 +++
>  lib/optee/optee.c   | 132 ++++
>  3 files changed, 149 insertions(+)
> 
[snip]

Looks good to me:
Reviewed-by: Jens Wiklander 

Cheers,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] image: fdt: copy possible optee nodes to a loaded devicetree

[Jens Wiklander]

Hi Heiko,

[+Igor]

On Tue, Oct 8, 2019 at 2:22 AM Heiko Stuebner  wrote:
>
> The loading convention for optee or any other tee on arm64 is as bl32
> parameter to the trusted-firmware. So TF-A gets invoked with the TEE as
> bl32 and main u-boot as bl33. Once it has done its startup TF-A jumps
> into the bl32 for the TEE startup, returns to TF-A and then jumps to bl33.
>
> All of them get passed a devicetree as parameter and all components often
> get loaded from a FIT image.
>
> OP-TEE will create additional nodes in that devicetree namely a firmware
> node and possibly multiple reserved-memory nodes.
>
> While this devicetree is used in main u-boot, in most cases it won't be
> the one passed to the actual kernel. Instead most boot commands will load
> a new devicetree from somewhere like mass storage of the network, so if
> that happens u-boot should transfer the optee nodes to that new devicetree.
>
> To make that happen introduce optee_copy_fdt_nodes() called from the dt
> setup function in image-fdt which after checking for the optee presence
> in the u-boot dt will make sure a optee node is present in the kernel dt
> and transfer any reserved-memory regions it can find.
>
> Signed-off-by: Heiko Stuebner 
> ---
> This goes together with my bl32 work for the spl_atf loader in
> https://patchwork.ozlabs.org/patch/1172565/
>
>  common/image-fdt.c  |   8 
>  include/tee/optee.h |   9 
>  lib/optee/optee.c   | 112 
>  3 files changed, 129 insertions(+)
>
> diff --git a/common/image-fdt.c b/common/image-fdt.c
> index 4247dcee0c..48388488d9 100644
> --- a/common/image-fdt.c
> +++ b/common/image-fdt.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #ifndef CONFIG_SYS_FDT_PAD
>  #define CONFIG_SYS_FDT_PAD 0x3000
> @@ -561,6 +562,13 @@ int image_setup_libfdt(bootm_headers_t *images, void 
> *blob,
> }
> }
>
> +   fdt_ret = optee_copy_fdt_nodes(gd->fdt_blob, blob);
> +   if (fdt_ret) {
> +   printf("ERROR: transfer of optee nodes to new fdt failed: 
> %s\n",
> +  fdt_strerror(fdt_ret));
> +   goto err;
> +   }
> +
> /* Delete the old LMB reservation */
> if (lmb)
> lmb_free(lmb, (phys_addr_t)(u32)(uintptr_t)blob,
> diff --git a/include/tee/optee.h b/include/tee/optee.h
> index 9446928fd4..121b30a303 100644
> --- a/include/tee/optee.h
> +++ b/include/tee/optee.h
> @@ -67,4 +67,13 @@ static inline int optee_verify_bootm_image(unsigned long 
> image_addr,
>  }
>  #endif
>
> +#if defined(CONFIG_OPTEE) && defined(CONFIG_OF_LIBFDT)
> +int optee_copy_fdt_nodes(const void *old_blob, void *new_blob);
> +#else
> +static inline int optee_copy_fdt_nodes(const void *old_blob, void *new_blob)
> +{
> +   return 0;
> +}
> +#endif
> +
>  #endif /* _OPTEE_H */
> diff --git a/lib/optee/optee.c b/lib/optee/optee.c
> index db92cd9af2..f484b12e67 100644
> --- a/lib/optee/optee.c
> +++ b/lib/optee/optee.c
> @@ -5,6 +5,8 @@
>   */
>
>  #include 
> +#include 
> +#include 
>  #include 
>
>  #define optee_hdr_err_msg \
> @@ -63,3 +65,113 @@ error:
>
> return ret;
>  }
> +
> +#if defined(CONFIG_OF_LIBFDT)
> +static int optee_add_firmware_node(void *fdt_blob)
> +{
> +   int offs, ret;
> +
> +   if (fdt_path_offset(fdt_blob, "/firmware/optee") >= 0) {
> +   debug("OP-TEE Device Tree node already exists");
> +   return 0;
> +   }
> +
> +   offs = fdt_path_offset(fdt_blob, "/firmware");
> +   if (offs < 0) {
> +   offs = fdt_path_offset(fdt_blob, "/");
> +   if (offs < 0)
> +   return offs;
> +
> +   offs = fdt_add_subnode(fdt_blob, offs, "firmware");
> +   if (offs < 0)
> +   return offs;
> +   }
> +
> +   offs = fdt_add_subnode(fdt_blob, offs, "optee");
> +   if (offs < 0)
> +   return ret;
> +
> +   ret = fdt_setprop_string(fdt_blob, offs, "compatible",
> +"linaro,optee-tz");
> +   if (ret < 0)
> +   return ret;
> +
> +   ret = fdt_setprop_string(fdt_blob, offs, "method", "smc");
> +   if (ret < 0)
> +   return ret;
> +
> +   return 0;
> +}
> +
> +int optee_copy_fdt_nodes(const void *old_blob, void *new_blob)
> +{
> +   int nodeoffset, subnode, ret;
> +   struct fdt_resource res;
> +
> +   if (fdt_check_header(old_blob))
> +   return -EINVAL;
> +
> +   /* only proceed if there is an /firmware/optee node */
> +   if (fdt_path_offset(old_blob, "/firmware/optee") < 0) {
> +   debug("No OP-TEE firmware node in old fdt, nothing to do");
> +   return 0;
> +   }
> +
> +   ret = optee_add_firmware_node(new_blob);

I think it's more safe to copy the OP-TEE node instead. The values of
"compatible" and "method" may be different on other platforms, "hvc"

Re: [U-Boot] "optee" Kbuild seems to have weird dependencies

[Jens Wiklander]

Hi Robert,

On Thu, Apr 18, 2019 at 10:19 PM Robert P. J. Day  wrote:
>
>
>   going over the u-boot.cfg generated from zynq_zed_defconfig, and
> noticed the following:
>
>   #define CONFIG_OPTEE_TZDRAM_BASE 0x
>   #define CONFIG_OPTEE_TZDRAM_SIZE 0x000
>
> i thought that was strange as CONFIG_OPTEE was not selected, so i
> checked, and here's the relevant snippet from lib/optee/Kconfig:
>
>   config OPTEE
> bool "Support OPTEE images"
> help
>   U-Boot can be configured to boot OPTEE images.
>   Selecting this option will enable shared OPTEE library code and
>   enable an OPTEE specific bootm command that will perform additional
>   OPTEE specific checks before booting an OPTEE image created with
>   mkimage.
>
>   config OPTEE_TZDRAM_SIZE
> hex "Amount of Trust-Zone RAM for the OPTEE image"
> default 0x000
> help
>   The size of pre-allocated Trust Zone DRAM to allocate for the OPTEE
>   runtime.
>
>   config OPTEE_TZDRAM_BASE
> hex "Base address of Trust-Zone RAM for the OPTEE image"
> default 0x
> help
>   The base address of pre-allocated Trust Zone DRAM for
>   the OPTEE runtime.
>
> those two Kbuild directives are (strangely?) not dependent on OPTEE,
> which is why they show up in u-boot.cfg. is this deliberate? i know
> nothing about TEE, but it seems odd that OPTEE-related settings don't
> depend on OPTEE.
>
>   am i misreading something?

It seems that the dependency was removed by Rui in c7b3a7ee5351
("optee: adjust dependencies and default values for dram").

If OPTEE_TZDRAM_SIZE and OPTEE_TZDRAM_BASE are needed or not depends
on the platform and should be selected in some way by the platform.

>
> rday
>
> p.s. the MAINTAINERS entry for TEE seems incomplete as well:
>
> TEE
> M:  Jens Wiklander 
> S:  Maintained
> F:  drivers/tee/
> F:  include/tee.h
> F:  include/tee/
>
>   one suspects that should include, at the very least:
>
>   * lib/optee
>   * include/config/optee
>

I understand that this is confusing. OP-TEE is supported by U-Boot in
two in two ways which are orthogonal.

We have loading and booting OP-TEE which is handled by lib/optee. In
this case U-Boot is used as a Secure world boot loader. This was added
by Bryan.

Then there's the TEE subsystem which includes a driver for
communicating with OP-TEE in Secure world. This is mostly to support
the Android Verified Boot 2.0 (AVB) use case, but can be used for
other purposes too. In this case U-Boot is a Normal world boot loader.
This was added by me.

I happen to know something about how OP-TEE is loaded, but I don't
know much about the boards on which U-Boot is used for that purpose. I
guess the best would be if Bryan added an entry for lib/optee in
MAINTAINERS.

Cheers,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] avb: add support for named persistent values

[Jens Wiklander]

Hi Igor,

Some comments below.

On Fri, Dec 14, 2018 at 07:45:03PM +0200, Igor Opaniuk wrote:
> AVB version 1.1 introduces support for named persistent values
> that must be tamper evident and allows AVB to store arbitrary key-value
> pairs [1].
> 
> Introduce implementation of two additional AVB operations
> read_persistent_value()/write_persistent_value() for retrieving/storing
> named persistent values.
> 
> Correspondent pull request in the OP-TEE OS project repo [2].
> 
> [1]: 
> https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> [2]: https://github.com/OP-TEE/optee_os/pull/2699
> 
> Signed-off-by: Igor Opaniuk 
> ---
> 
> Changes in v2:
> - fix output format for avb read_pvalue/write_pvalue commands
> - fix issue with named value buffer size
> 
>  cmd/avb.c  |  78 +
>  common/avb_verify.c| 122 
> +
>  include/tee.h  |   2 +
>  include/tee/optee_ta_avb.h |  16 ++
>  4 files changed, 218 insertions(+)
> 
> diff --git a/cmd/avb.c b/cmd/avb.c
> index ff00be4..8387cc7 100644
> --- a/cmd/avb.c
> +++ b/cmd/avb.c
> @@ -340,6 +340,76 @@ int do_avb_is_unlocked(cmd_tbl_t *cmdtp, int flag,
>   return CMD_RET_FAILURE;
>  }
>  
> +int do_avb_read_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> + const char *name;
> + size_t bytes;
> + size_t bytes_read;
> + void *buffer;
> +
> + if (!avb_ops) {
> + printf("AVB 2.0 is not initialized, run 'avb init' first\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + name = argv[1];
> + bytes = simple_strtoul(argv[2], NULL, 10);

This parses without error check and would for instance parse 123hello as
123.

> + buffer = malloc(bytes);
> + if (!buffer)
> + return CMD_RET_FAILURE;
> +
> + printf("Reading persistent value, name = %s, bytes = %ld\n",
> +name, bytes);
> + if (avb_ops->read_persistent_value(avb_ops, name, bytes, buffer,
> +_read) == AVB_IO_RESULT_OK) {
> + printf("Read %ld bytes, value = %s\n", bytes_read,
> +(char *)buffer);
> + free(buffer);
> + return CMD_RET_SUCCESS;
> + }
> +
> + printf("Failed to write in partition\n");

read

> +
> + free(buffer);
> +
> + return CMD_RET_FAILURE;
> +}
> +
> +int do_avb_write_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + const char *name;
> + const char *value;
> +
> + if (!avb_ops) {
> + printf("AVB 2.0 is not initialized, run 'avb init' first\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + name = argv[1];
> + value = argv[2];
> +
> + printf("Writing persistent value, name = %s, value = %s\n",
> +name, value);
> + if (avb_ops->write_persistent_value(avb_ops, name, strlen(value) + 1,
> + (const uint8_t *)value) ==
> + AVB_IO_RESULT_OK) {
> + printf("Wrote %ld bytes\n", strlen(value) + 1);
> + return CMD_RET_SUCCESS;
> + }
> +
> + printf("Failed to write persistent value\n");
> +
> + return CMD_RET_FAILURE;
> +}
> +
>  static cmd_tbl_t cmd_avb[] = {
>   U_BOOT_CMD_MKENT(init, 2, 0, do_avb_init, "", ""),
>   U_BOOT_CMD_MKENT(read_rb, 2, 0, do_avb_read_rb, "", ""),
> @@ -350,6 +420,10 @@ static cmd_tbl_t cmd_avb[] = {
>   U_BOOT_CMD_MKENT(read_part_hex, 4, 0, do_avb_read_part_hex, "", ""),
>   U_BOOT_CMD_MKENT(write_part, 5, 0, do_avb_write_part, "", ""),
>   U_BOOT_CMD_MKENT(verify, 1, 0, do_avb_verify_part, "", ""),
> +#ifdef CONFIG_OPTEE_TA_AVB
> + U_BOOT_CMD_MKENT(read_pvalue, 3, 0, do_avb_read_pvalue, "", ""),
> + U_BOOT_CMD_MKENT(write_pvalue, 3, 0, do_avb_write_pvalue, "", ""),
> +#endif
>  };
>  
>  static int do_avb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> @@ -384,6 +458,10 @@ U_BOOT_CMD(
>   "partition  and print to stdout\n"
>   "avb write_part - write  bytes 
> to\n"
>   " by  using data from \n"
> +#ifdef CONFIG_OPTEE_TA_AVB
> + "avb read_pvalue   - read a persistent value \n"
> + "avb write_pvalue   - write a persistent value \n"
> +#endif
>   "avb verify - run verification process using hash data\n"
>   "from vbmeta structure\n"
>   );
> diff --git a/common/avb_verify.c b/common/avb_verify.c
> index a8c5a3e..292ad8f 100644
> --- a/common/avb_verify.c
> +++ b/common/avb_verify.c
> @@ -647,6 +647,10 @@ static AvbIOResult invoke_func(struct AvbOpsData 
> *ops_data, u32 func,
>   return AVB_IO_RESULT_OK;
>   case TEE_ERROR_OUT_OF_MEMORY:
>   return AVB_IO_RESULT_ERROR_OOM;
> + 

Re: [U-Boot] [PATCH 1/1] tee: change return code for REE FS supplicant cmd

[Jens Wiklander]

On Tue, Dec 4, 2018 at 1:37 PM Igor Opaniuk  wrote:
>
> If OP-TEE core is compiled with support of REE FS and RPMB
> at the same time (CFG_RPMB_FS ?= y; CFG_RPMB_FS ?= y), and persistent
> storage API is used with TEE_STORAGE_PRIVATE storage id, it will
> lead to TA panic.
>
> E/TC:? 0 TA panicked with code 0x0009
> .
> E/TC:? 0 Call stack:
> E/TC:? 0  0x4002f2f8 TEE_OpenPersistentObject at
> lib/libutee/tee_api_objects.c:422
>
> In this particular case TEE_ERROR_STORAGE_NOT_AVAILABLE is more suitable
> than TEE_ERROR_NOT_IMPLEMENTED, as it provides to a TA a possibility
> to handle this error code [1].
>
> From GPD TEE Internal Core specification [2]:
> TEE_ERROR_STORAGE_NOT_AVAILABLE - if the persistent object is stored in a
> storage area which is currently inaccessible. It may be associated with
> the device but unplugged, busy, or inaccessible for some other reason.
>
> [1]: 
> https://github.com/OP-TEE/optee_os/blob/94db01ef448d1e552161c2d861d57a5f8bda0cc0/lib/libutee/tee_api_objects.c#L419
> [2]: 
> https://globalplatform.org/wp-content/uploads/2018/06/GPD_TEE_Internal_Core_API_Specification_v1.1.2.50_PublicReview.pdf
>
> Signed-off-by: Igor Opaniuk 
> ---
>  drivers/tee/optee/supplicant.c | 4 ++--
>  include/tee.h  | 1 +
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tee/optee/supplicant.c b/drivers/tee/optee/supplicant.c
> index b1ea65b..c5726ec 100644
> --- a/drivers/tee/optee/supplicant.c
> +++ b/drivers/tee/optee/supplicant.c
> @@ -82,8 +82,8 @@ void optee_suppl_cmd(struct udevice *dev, struct tee_shm 
> *shm_arg,
> cmd_shm_free(arg);
> break;
> case OPTEE_MSG_RPC_CMD_FS:
> -   debug("OPTEE_MSG_RPC_CMD_FS not implemented\n");
> -   arg->ret = TEE_ERROR_NOT_IMPLEMENTED;
> +   debug("REE FS storage isn't available\n");
> +   arg->ret = TEE_ERROR_STORAGE_NOT_AVAILABLE;
> break;
> case OPTEE_MSG_RPC_CMD_RPMB:
> optee_suppl_cmd_rpmb(dev, arg);
> diff --git a/include/tee.h b/include/tee.h
> index 98b1c9c..edd9f9b 100644
> --- a/include/tee.h
> +++ b/include/tee.h
> @@ -34,6 +34,7 @@
>   * struct tee_version_data::gen_caps
>   */
>  #define TEE_SUCCESS0x
> +#define TEE_ERROR_STORAGE_NOT_AVAILABLE0xf013
>  #define TEE_ERROR_GENERIC  0x
>  #define TEE_ERROR_BAD_PARAMETERS   0x0006
>  #define TEE_ERROR_ITEM_NOT_FOUND   0x0008
> --
> 2.7.4
>

Looks good to me:
Reviewed-by: Jens Wiklander 

Thanks,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] test: tee: fix resource leak in dm_test_tee()

[Jens Wiklander]

Fixes possible resource leak in dm_test_tee() reported by Coverity.

Reported-by: Coverity (CID: 184175)
Signed-off-by: Jens Wiklander 

---

 test/dm/tee.c | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/test/dm/tee.c b/test/dm/tee.c
index 13e3f4003a7d..22f05a421978 100644
--- a/test/dm/tee.c
+++ b/test/dm/tee.c
@@ -49,7 +49,12 @@ static int match(struct tee_version_data *vers, const void 
*data)
return vers->gen_caps & TEE_GEN_CAP_GP;
 }
 
-static int dm_test_tee(struct unit_test_state *uts)
+struct test_tee_vars {
+   struct tee_shm *reg_shm;
+   struct tee_shm *alloc_shm;
+};
+
+static int test_tee(struct unit_test_state *uts, struct test_tee_vars *vars)
 {
struct tee_version_data vers;
struct udevice *dev;
@@ -57,8 +62,6 @@ static int dm_test_tee(struct unit_test_state *uts)
u32 session = 0;
int rc;
u8 data[128];
-   struct tee_shm *reg_shm;
-   struct tee_shm *alloc_shm;
 
dev = tee_find_device(NULL, match, NULL, );
ut_assert(dev);
@@ -77,22 +80,36 @@ static int dm_test_tee(struct unit_test_state *uts)
ut_assert(!state->session);
 
ut_assert(!state->num_shms);
-   rc = tee_shm_register(dev, data, sizeof(data), 0, _shm);
+   rc = tee_shm_register(dev, data, sizeof(data), 0, >reg_shm);
ut_assert(!rc);
ut_assert(state->num_shms == 1);
 
-   rc = tee_shm_alloc(dev, 256, 0, _shm);
+   rc = tee_shm_alloc(dev, 256, 0, >alloc_shm);
ut_assert(!rc);
ut_assert(state->num_shms == 2);
 
-   ut_assert(tee_shm_is_registered(reg_shm, dev));
-   ut_assert(tee_shm_is_registered(alloc_shm, dev));
+   ut_assert(tee_shm_is_registered(vars->reg_shm, dev));
+   ut_assert(tee_shm_is_registered(vars->alloc_shm, dev));
 
-   tee_shm_free(reg_shm);
-   tee_shm_free(alloc_shm);
+   tee_shm_free(vars->reg_shm);
+   vars->reg_shm = NULL;
+   tee_shm_free(vars->alloc_shm);
+   vars->alloc_shm = NULL;
ut_assert(!state->num_shms);
 
return 0;
 }
 
+static int dm_test_tee(struct unit_test_state *uts)
+{
+   struct test_tee_vars vars = { NULL, NULL };
+   int rc = test_tee(uts, );
+
+   /* In case test_tee() asserts these may still remain allocated */
+   tee_shm_free(vars.reg_shm);
+   tee_shm_free(vars.alloc_shm);
+
+   return rc;
+}
+
 DM_TEST(dm_test_tee, DM_TESTF_SCAN_FDT);
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 00/19] AVB using OP-TEE

[Jens Wiklander]

Hi Simon,

On Tue, Oct 2, 2018 at 1:21 PM, Simon Glass  wrote:
> Hi Jen,
>
> On 25 September 2018 at 07:40, Jens Wiklander  
> wrote:
>> Hi,
>>
>> This adds support for storing AVB rollback indexes in the RPMB partition.
>> The RPMB partition (content and key) is managed by OP-TEE
>> (https://www.op-tee.org/) which is a secure OS leveraging ARM TrustZone.
>>
>> The Linux kernel can already support OP-TEE with reading and updating
>> rollback indexes in the RPMB partition, the catch is that this is needed
>> before the kernel has booted.
>>
>> The design here is the same as what is in the Linux kernel, with the
>> exception that the user space daemon tee-supplicant is integrated in the
>> OP-TEE driver here (drivers/tee/optee/supplicant.c) instead. A new uclass
>> (UCLASS_TEE) is introduced to provide an abstraction for interfacing with a
>> Trusted Execution Environment (TEE). There's also the OP-TEE driver using
>> UCLASS_TEE for registration.
>>
>> A Trusted Application (TA) interface is added to be used by the AVB verify
>> functions which are updated accordingly. The TA is managed by OP-TEE and is
>> executed in a secure TrustZone protected environment.
>>
>> The header files drivers/tee/optee/optee_{msg,msg_supplicant,smc}.h and
>> include/tee/optee_ta_avb.h are copied from
>> https://github.com/OP-TEE/optee_os/tree/master more or less unmodified.
>> They may need to be updated from time to time in order to support new
>> features.
>>
>> In MMC there's a new function, mmc_rpmb_route_frames(), which as the name
>> suggests is used to route RPMB frames to/from the MMC. This saves OP-TEE
>> from implementing an MMC driver which would need to share resources with
>> its counterpart here in U-Boot.
>>
>> This was tested on a Hikey (Kirin 620) board.
>>
>> I've added myself as maintainer of the TEE stuff.
>>
>> changes in v4:
>> * Addressed review comments from Simon Glass
>> * Rebased on v2018.09
>> * "avb_verify: bugfix avb_ops_free() skipping free" removed due to the rebase
>> * Commits "dt/bindings: add bindings for optee",
>>   "sandbox: imply CONFIG_TEE (TEE uclass)",
>>   "tee: add sandbox driver",
>>   "avb_verify: support using OP-TEE TA AVB",
>>   "test_avb: Update patiensepymark.buildconfigspec information for the AVB 
>> tests",
>>   "Kconfig: sandbox: enable cmd_avb and dependencies",
>>   Reviewed-by: Simon Glass 
>> * Added descriptions of additional structs and functions
>> * In commit "avb_verify: support sandbox configuration" avoid the
>>   #ifdef CONFIG_SANDBOX in get_sector_buf() as suggested by Simon.
>
> You might consider using patman, where you add the change log for each
> patch individually, and it produces the change log for the series
> automatically.
>
> I find it harder to review patches which don't have their own
> individual change log.

I'll try patman next time. A big thank you for reviewing this patch series.

--
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 19/19] Kconfig: sandbox: enable cmd_avb and dependencies

[Jens Wiklander]

Enables cmd_avb and its dependencies need to run the AVB tests.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 arch/Kconfig | 4 
 drivers/fastboot/Kconfig | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 8f10f3fc06e8..543362578f50 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -92,6 +92,10 @@ config SANDBOX
imply LZMA
imply SCSI
imply TEE
+   imply AVB_VERIFY
+   imply LIBAVB
+   imply CMD_AVB
+   imply UDP_FUNCTION_FASTBOOT
 
 config SH
bool "SuperH architecture"
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index bc25ea1d9c7a..d63ecdd27e4b 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -35,6 +35,7 @@ config FASTBOOT_BUF_ADDR
ROCKCHIP_RK3399
default 0x28 if ROCKCHIP_RK3368
default 0x10 if ARCH_ZYNQMP
+   default 0 if SANDBOX
help
  The fastboot protocol requires a large memory buffer for
  downloads. Define this to the starting RAM address to use for
@@ -45,6 +46,7 @@ config FASTBOOT_BUF_SIZE
default 0x800 if ARCH_ROCKCHIP
default 0x600 if ARCH_ZYNQMP
default 0x200 if ARCH_SUNXI
+   default 0x8192 if SANDBOX
default 0x700
help
  The fastboot protocol requires a large memory buffer for
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 17/19] test_avb: Update pymark.buildconfigspec information for the AVB tests

[Jens Wiklander]

Update the pymark.buildconfigspec to depend on 'cmd_mmc' in addition to
'cmd_avb' for those tests that needs more a more complete MMC
implementation or the "mmc" command.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 test/py/tests/test_avb.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index 7996e4845db3..9683fd80d074 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -23,7 +23,7 @@ mmc_dev = 1
 temp_addr = 0x9000
 temp_addr2 = 0x90002000
 
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
 def test_avb_verify(u_boot_console):
 """Run AVB 2.0 boot verification chain with avb subset of commands
 """
@@ -36,7 +36,7 @@ def test_avb_verify(u_boot_console):
 assert response.find(success_str)
 
 
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
 def test_avb_mmc_uuid(u_boot_console):
 """Check if 'avb get_uuid' works, compare results with
 'part list mmc 1' output
@@ -78,6 +78,7 @@ def test_avb_read_rb(u_boot_console):
 assert response == ''
 
 response = u_boot_console.run_command('avb read_rb 1')
+assert response == 'Rollback index: 0'
 
 
 @pytest.mark.buildconfigspec('cmd_avb')
@@ -89,9 +90,10 @@ def test_avb_is_unlocked(u_boot_console):
 assert response == ''
 
 response = u_boot_console.run_command('avb is_unlocked')
+assert response == 'Unlocked = 1'
 
 
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
 def test_avb_mmc_read(u_boot_console):
 """Test mmc read operation
 """
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 15/19] test: tee: test TEE uclass

[Jens Wiklander]

Tests the TEE uclass with a sandbox tee driver.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 test/dm/Makefile |  1 +
 test/dm/tee.c| 98 
 2 files changed, 99 insertions(+)
 create mode 100644 test/dm/tee.c

diff --git a/test/dm/Makefile b/test/dm/Makefile
index 67c1fe6d0142..b1eedf4a6ee2 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -46,4 +46,5 @@ obj-$(CONFIG_SPMI) += spmi.o
 obj-$(CONFIG_WDT) += wdt.o
 obj-$(CONFIG_AXI) += axi.o
 obj-$(CONFIG_MISC) += misc.o
+obj-$(CONFIG_TEE) += tee.o
 endif
diff --git a/test/dm/tee.c b/test/dm/tee.c
new file mode 100644
index ..ab1c7da9d2d3
--- /dev/null
+++ b/test/dm/tee.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int open_session(struct udevice *dev, u32 *session)
+{
+   struct tee_open_session_arg arg;
+   const struct tee_optee_ta_uuid uuid = TA_AVB_UUID;
+   int rc;
+
+   memset(, 0, sizeof(arg));
+   tee_optee_ta_uuid_to_octets(arg.uuid, );
+   rc = tee_open_session(dev, , 0, NULL);
+   if (rc)
+   return rc;
+   if (arg.ret)
+   return -EIO;
+   *session = arg.session;
+
+   return 0;
+}
+
+static int invoke_func(struct udevice *dev, u32 session)
+{
+   struct tee_param param = { .attr = TEE_PARAM_ATTR_TYPE_VALUE_OUTPUT };
+   struct tee_invoke_arg arg;
+
+   memset(, 0, sizeof(arg));
+   arg.session = session;
+   arg.func = TA_AVB_CMD_READ_LOCK_STATE;
+
+   if (tee_invoke_func(dev, , 1, ) || arg.ret)
+   return -1;
+
+   return 0;
+}
+
+static int match(struct tee_version_data *vers, const void *data)
+{
+   return vers->gen_caps & TEE_GEN_CAP_GP;
+}
+
+static int dm_test_tee(struct unit_test_state *uts)
+{
+   struct tee_version_data vers;
+   struct udevice *dev;
+   struct sandbox_tee_state *state;
+   u32 session;
+   int rc;
+   u8 data[128];
+   struct tee_shm *reg_shm;
+   struct tee_shm *alloc_shm;
+
+   dev = tee_find_device(NULL, match, NULL, );
+   ut_assert(dev);
+   state = dev_get_priv(dev);
+   ut_assert(!state->session);
+
+   rc = open_session(dev, );
+   ut_assert(!rc);
+   ut_assert(session == state->session);
+
+   rc = invoke_func(dev, session);
+   ut_assert(!rc);
+
+   rc = tee_close_session(dev, session);
+   ut_assert(!rc);
+   ut_assert(!state->session);
+
+   ut_assert(!state->num_shms);
+   rc = tee_shm_register(dev, data, sizeof(data), 0, _shm);
+   ut_assert(!rc);
+   ut_assert(state->num_shms == 1);
+
+   rc = tee_shm_alloc(dev, 256, 0, _shm);
+   ut_assert(!rc);
+   ut_assert(state->num_shms == 2);
+
+   ut_assert(tee_shm_is_registered(reg_shm, dev));
+   ut_assert(tee_shm_is_registered(alloc_shm, dev));
+
+   tee_shm_free(reg_shm);
+   tee_shm_free(alloc_shm);
+   ut_assert(!state->num_shms);
+
+   return 0;
+}
+
+DM_TEST(dm_test_tee, DM_TESTF_SCAN_FDT);
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 16/19] avb_verify: support using OP-TEE TA AVB

[Jens Wiklander]

With CONFIG_OPTEE_TA_AVB use the trusted application AVB provided by
OP-TEE to manage rollback indexes and device-lock status.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 common/avb_verify.c  | 118 ++-
 doc/README.avb2  |  13 +
 include/avb_verify.h |   4 ++
 3 files changed, 134 insertions(+), 1 deletion(-)

diff --git a/common/avb_verify.c b/common/avb_verify.c
index f8c6ae5566ae..a8c5a3e7db36 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static const unsigned char avb_root_pub[1032] = {
0x0, 0x0, 0x10, 0x0, 0x55, 0xd9, 0x4, 0xad, 0xd8, 0x4,
@@ -600,6 +602,65 @@ static AvbIOResult validate_vbmeta_public_key(AvbOps *ops,
return AVB_IO_RESULT_OK;
 }
 
+#ifdef CONFIG_OPTEE_TA_AVB
+static int get_open_session(struct AvbOpsData *ops_data)
+{
+   struct udevice *tee = NULL;
+
+   while (!ops_data->tee) {
+   const struct tee_optee_ta_uuid uuid = TA_AVB_UUID;
+   struct tee_open_session_arg arg;
+   int rc;
+
+   tee = tee_find_device(tee, NULL, NULL, NULL);
+   if (!tee)
+   return -ENODEV;
+
+   memset(, 0, sizeof(arg));
+   tee_optee_ta_uuid_to_octets(arg.uuid, );
+   rc = tee_open_session(tee, , 0, NULL);
+   if (!rc) {
+   ops_data->tee = tee;
+   ops_data->session = arg.session;
+   }
+   }
+
+   return 0;
+}
+
+static AvbIOResult invoke_func(struct AvbOpsData *ops_data, u32 func,
+  ulong num_param, struct tee_param *param)
+{
+   struct tee_invoke_arg arg;
+
+   if (get_open_session(ops_data))
+   return AVB_IO_RESULT_ERROR_IO;
+
+   memset(, 0, sizeof(arg));
+   arg.func = func;
+   arg.session = ops_data->session;
+
+   if (tee_invoke_func(ops_data->tee, , num_param, param))
+   return AVB_IO_RESULT_ERROR_IO;
+   switch (arg.ret) {
+   case TEE_SUCCESS:
+   return AVB_IO_RESULT_OK;
+   case TEE_ERROR_OUT_OF_MEMORY:
+   return AVB_IO_RESULT_ERROR_OOM;
+   case TEE_ERROR_TARGET_DEAD:
+   /*
+* The TA has paniced, close the session to reload the TA
+* for the next request.
+*/
+   tee_close_session(ops_data->tee, ops_data->session);
+   ops_data->tee = NULL;
+   return AVB_IO_RESULT_ERROR_IO;
+   default:
+   return AVB_IO_RESULT_ERROR_IO;
+   }
+}
+#endif
+
 /**
  * read_rollback_index() - gets the rollback index corresponding to the
  * location of given by @out_rollback_index.
@@ -615,6 +676,7 @@ static AvbIOResult read_rollback_index(AvbOps *ops,
   size_t rollback_index_slot,
   u64 *out_rollback_index)
 {
+#ifndef CONFIG_OPTEE_TA_AVB
/* For now we always return 0 as the stored rollback index. */
printf("%s not supported yet\n", __func__);
 
@@ -622,6 +684,27 @@ static AvbIOResult read_rollback_index(AvbOps *ops,
*out_rollback_index = 0;
 
return AVB_IO_RESULT_OK;
+#else
+   AvbIOResult rc;
+   struct tee_param param[2];
+
+   if (rollback_index_slot >= TA_AVB_MAX_ROLLBACK_LOCATIONS)
+   return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
+
+   memset(param, 0, sizeof(param));
+   param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+   param[0].u.value.a = rollback_index_slot;
+   param[1].attr = TEE_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+
+   rc = invoke_func(ops->user_data, TA_AVB_CMD_READ_ROLLBACK_INDEX,
+ARRAY_SIZE(param), param);
+   if (rc)
+   return rc;
+
+   *out_rollback_index = (u64)param[1].u.value.a << 32 |
+ (u32)param[1].u.value.b;
+   return AVB_IO_RESULT_OK;
+#endif
 }
 
 /**
@@ -639,10 +722,27 @@ static AvbIOResult write_rollback_index(AvbOps *ops,
size_t rollback_index_slot,
u64 rollback_index)
 {
+#ifndef CONFIG_OPTEE_TA_AVB
/* For now this is a no-op. */
printf("%s not supported yet\n", __func__);
 
return AVB_IO_RESULT_OK;
+#else
+   struct tee_param param[2];
+
+   if (rollback_index_slot >= TA_AVB_MAX_ROLLBACK_LOCATIONS)
+   return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
+
+   memset(param, 0, sizeof(param));
+   param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+   param[0].u.value.a = rollback_index_slot;
+   param[1].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+   param[1].u.value.a = (u32)(rollback_index >> 32);
+   param[1].u.value.b = (u32)rollback_index;
+
+   r

[U-Boot] [PATCH v4 18/19] avb_verify: support sandbox configuration

[Jens Wiklander]

Change get_sector_buf() to use map_sysmem() to get a pointer to the
CONFIG_FASTBOOT_BUF_ADDR in memory.

Signed-off-by: Jens Wiklander 
---
 include/avb_verify.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/avb_verify.h b/include/avb_verify.h
index a532a2331aea..18278f829e41 100644
--- a/include/avb_verify.h
+++ b/include/avb_verify.h
@@ -9,6 +9,7 @@
 #define _AVB_VERIFY_H
 
 #include <../lib/libavb/libavb.h>
+#include 
 #include 
 
 #define AVB_MAX_ARGS   1024
@@ -76,7 +77,7 @@ static inline size_t get_sector_buf_size(void)
 
 static inline void *get_sector_buf(void)
 {
-   return (void *)CONFIG_FASTBOOT_BUF_ADDR;
+   return map_sysmem(CONFIG_FASTBOOT_BUF_ADDR, CONFIG_FASTBOOT_BUF_SIZE);
 }
 
 static inline bool is_buf_unaligned(void *buffer)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 13/19] sandbox: imply CONFIG_TEE (TEE uclass)

[Jens Wiklander]

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 arch/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index bf1b4a9afac6..8f10f3fc06e8 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -91,6 +91,7 @@ config SANDBOX
imply HASH_VERIFY
imply LZMA
imply SCSI
+   imply TEE
 
 config SH
bool "SuperH architecture"
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 12/19] sandbox: dt: add sandbox_tee node

[Jens Wiklander]

Adds a sandbox_tee node to enable the sandbox tee driver in all the
sandbox dts files.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 arch/sandbox/dts/sandbox.dts   | 4 
 arch/sandbox/dts/sandbox64.dts | 4 
 arch/sandbox/dts/test.dts  | 4 
 3 files changed, 12 insertions(+)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 6ac37f1ed7be..af7f12aa5889 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -322,6 +322,10 @@
reg = <0x0 0x400>;
};
};
+
+   sandbox_tee {
+   compatible = "sandbox,tee";
+   };
 };
 
 #include "cros-ec-keyboard.dtsi"
diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
index 9e65d2fda3d3..0e32fdad9d81 100644
--- a/arch/sandbox/dts/sandbox64.dts
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -311,6 +311,10 @@
};
};
};
+
+   sandbox_tee {
+   compatible = "sandbox,tee";
+   };
 };
 
 #include "cros-ec-keyboard.dtsi"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 366826333181..997f8f996f23 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -630,6 +630,10 @@
};
};
};
+
+   sandbox_tee {
+   compatible = "sandbox,tee";
+   };
 };
 
 #include "sandbox_pmic.dtsi"
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 11/19] tee: optee: support AVB trusted application

[Jens Wiklander]

Adds configuration option OPTEE_TA_AVB and a header file describing the
interface to the Android Verified Boot 2.0 (AVB) trusted application
provided by OP-TEE.

Tested-by: Igor Opaniuk 
Reviewed-by: Igor Opaniuk 
Signed-off-by: Jens Wiklander 
---
 MAINTAINERS|  1 +
 drivers/tee/optee/Kconfig  | 16 +
 drivers/tee/tee-uclass.c   | 24 +++
 include/tee.h  | 38 ++
 include/tee/optee_ta_avb.h | 48 ++
 5 files changed, 127 insertions(+)
 create mode 100644 include/tee/optee_ta_avb.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b085ad3acd6..1c96ece8cc9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -590,6 +590,7 @@ M:  Jens Wiklander 
 S: Maintained
 F: drivers/tee/
 F: include/tee.h
+F: include/tee/
 
 UBI
 M: Kyungmin Park 
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index 7484e6fea114..dbfa7846a30f 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -9,3 +9,19 @@ config OPTEE
  mechanism. This driver can request services from OP-TEE, but also
  handle Remote Procedure Calls (RPC) from OP-TEE needed to
  execute a service. For more information see: https://www.op-tee.org
+
+if OPTEE
+
+menu "OP-TEE options"
+
+config OPTEE_TA_AVB
+   bool "Support AVB TA"
+   default y
+   help
+ Enables support for the AVB Trusted Application (TA) in OP-TEE.
+ The TA can support the "avb" subcommands "read_rb", "write"rb"
+ and "is_unlocked".
+
+endmenu
+
+endif
diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
index 1bee54ebf4af..abb88c0fee53 100644
--- a/drivers/tee/tee-uclass.c
+++ b/drivers/tee/tee-uclass.c
@@ -207,3 +207,27 @@ UCLASS_DRIVER(tee) = {
.pre_probe = tee_pre_probe,
.pre_remove = tee_pre_remove,
 };
+
+void tee_optee_ta_uuid_from_octets(struct tee_optee_ta_uuid *d,
+  const u8 s[TEE_UUID_LEN])
+{
+   d->time_low = ((u32)s[0] << 24) | ((u32)s[1] << 16) |
+ ((u32)s[2] << 8) | s[3],
+   d->time_mid = ((u32)s[4] << 8) | s[5];
+   d->time_hi_and_version = ((u32)s[6] << 8) | s[7];
+   memcpy(d->clock_seq_and_node, s + 8, sizeof(d->clock_seq_and_node));
+}
+
+void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
+const struct tee_optee_ta_uuid *s)
+{
+   d[0] = s->time_low >> 24;
+   d[1] = s->time_low >> 16;
+   d[2] = s->time_low >> 8;
+   d[3] = s->time_low;
+   d[4] = s->time_mid >> 8;
+   d[5] = s->time_mid;
+   d[6] = s->time_hi_and_version >> 8;
+   d[7] = s->time_hi_and_version;
+   memcpy(d + 8, s->clock_seq_and_node, sizeof(s->clock_seq_and_node));
+}
diff --git a/include/tee.h b/include/tee.h
index b86dbec257b4..98b1c9cc693a 100644
--- a/include/tee.h
+++ b/include/tee.h
@@ -49,6 +49,22 @@
 #define TEE_ORIGIN_TRUSTED_APP 0x0004
 
 struct udevice;
+
+/**
+ * struct tee_optee_ta_uuid - OP-TEE Trusted Application (TA) UUID format
+ *
+ * Used to identify an OP-TEE TA and define suitable to initialize structs
+ * of this format is distributed with the interface of the TA. The
+ * individual fields of this struct doesn't have any special meaning in
+ * OP-TEE. See RFC4122 for details on the format.
+ */
+struct tee_optee_ta_uuid {
+   u32 time_low;
+   u16 time_mid;
+   u16 time_hi_and_version;
+   u8 clock_seq_and_node[8];
+};
+
 /**
  * struct tee_shm - memory shared with the TEE
  * @dev:   The TEE device
@@ -333,4 +349,26 @@ int tee_close_session(struct udevice *dev, u32 session);
 int tee_invoke_func(struct udevice *dev, struct tee_invoke_arg *arg,
uint num_param, struct tee_param *param);
 
+/**
+ * tee_optee_ta_uuid_from_octets() - Converts to struct tee_optee_ta_uuid
+ * @d: Destination struct
+ * @s: Source UUID octets
+ *
+ * Conversion to a struct tee_optee_ta_uuid represantion from binary octet
+ * representation.
+ */
+void tee_optee_ta_uuid_from_octets(struct tee_optee_ta_uuid *d,
+  const u8 s[TEE_UUID_LEN]);
+
+/**
+ * tee_optee_ta_uuid_to_octets() - Converts from struct tee_optee_ta_uuid
+ * @d: Destination UUID octets
+ * @s: Source struct
+ *
+ * Conversion from a struct tee_optee_ta_uuid represantion to binary octet
+ * representation.
+ */
+void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
+const struct tee_optee_ta_uuid *s);
+
 #endif /* __TEE_H */
diff --git a/include/tee/optee_ta_avb.h b/include/tee/optee_ta_avb.h
new file mode 100644
index ..074386af19a1
--- /dev/null
+++ b/include/tee/optee_ta_avb.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+/* Copyright (c) 201

[U-Boot] [PATCH v4 10/19] optee: support routing of rpmb data frames to mmc

[Jens Wiklander]

Adds support in optee supplicant to route signed (MACed) RPMB frames
from OP-TEE Secure OS to MMC and vice versa to manipulate the RPMB
partition.

Tested-by: Igor Opaniuk 
Signed-off-by: Jens Wiklander 
---
 drivers/tee/optee/Makefile|   1 +
 drivers/tee/optee/core.c  |   8 ++
 drivers/tee/optee/optee_private.h |  55 -
 drivers/tee/optee/rpmb.c  | 181 ++
 drivers/tee/optee/supplicant.c|   3 +
 5 files changed, 247 insertions(+), 1 deletion(-)
 create mode 100644 drivers/tee/optee/rpmb.c

diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
index 6148feb474a5..928d3f80027f 100644
--- a/drivers/tee/optee/Makefile
+++ b/drivers/tee/optee/Makefile
@@ -2,3 +2,4 @@
 
 obj-y += core.o
 obj-y += supplicant.o
+obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 726382da9bb8..7f870f2f735d 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -315,6 +315,13 @@ static u32 do_call_with_arg(struct udevice *dev, struct 
optee_msg_arg *arg)
param.a3 = res.a3;
handle_rpc(dev, , _list);
} else {
+   /*
+* In case we've accessed RPMB to serve an RPC
+* request we need to restore the previously
+* selected partition as the caller may expect it
+* to remain unchanged.
+*/
+   optee_suppl_rpmb_release(dev);
return call_err_to_res(res.a0);
}
}
@@ -651,4 +658,5 @@ U_BOOT_DRIVER(optee) = {
.probe = optee_probe,
.ops = _ops,
.platdata_auto_alloc_size = sizeof(struct optee_pdata),
+   .priv_auto_alloc_size = sizeof(struct optee_private),
 };
diff --git a/drivers/tee/optee/optee_private.h 
b/drivers/tee/optee/optee_private.h
index 35adb83afcc7..9442d1c176bc 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -6,7 +6,60 @@
 #ifndef __OPTEE_PRIVATE_H
 #define __OPTEE_PRIVATE_H
 
+#include 
+#include 
+
+/**
+ * struct optee_private - OP-TEE driver private data
+ * @rpmb_mmc:  mmc device for the RPMB partition
+ * @rpmb_dev_id:   mmc device id matching @rpmb_mmc
+ * @rpmb_original_part:the previosly active partition on the mmc 
device,
+ * used to restore active the partition when the RPMB
+ * accesses are finished
+ */
+struct optee_private {
+   struct mmc *rpmb_mmc;
+   int rpmb_dev_id;
+   int rpmb_original_part;
+};
+
+struct optee_msg_arg;
+
+void optee_suppl_cmd(struct udevice *dev, struct tee_shm *shm_arg,
+void **page_list);
+
+#ifdef CONFIG_SUPPORT_EMMC_RPMB
+/**
+ * optee_suppl_cmd_rpmb() - route RPMB frames to mmc
+ * @dev:   device with the selected RPMB partition
+ * @arg:   OP-TEE message holding the frames to transmit to the mmc
+ * and space for the response frames.
+ *
+ * Routes signed (MACed) RPMB frames from OP-TEE Secure OS to MMC and vice
+ * versa to manipulate the RPMB partition.
+ */
+void optee_suppl_cmd_rpmb(struct udevice *dev, struct optee_msg_arg *arg);
+
+/**
+ * optee_suppl_rpmb_release() - release mmc device
+ * @dev:   mmc device
+ *
+ * Releases the mmc device and restores the previously selected partition.
+ */
+void optee_suppl_rpmb_release(struct udevice *dev);
+#else
+static inline void optee_suppl_cmd_rpmb(struct udevice *dev,
+   struct optee_msg_arg *arg)
+{
+   debug("OPTEE_MSG_RPC_CMD_RPMB not implemented\n");
+   arg->ret = TEE_ERROR_NOT_IMPLEMENTED;
+}
+
+static inline void optee_suppl_rpmb_release(struct udevice *dev)
+{
+}
+#endif
+
 void *optee_alloc_and_init_page_list(void *buf, ulong len, u64 *phys_buf_ptr);
-void optee_suppl_cmd(struct udevice *dev, void *shm, void **page_list);
 
 #endif /* __OPTEE_PRIVATE_H */
diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
new file mode 100644
index ..955155b3f8b1
--- /dev/null
+++ b/drivers/tee/optee/rpmb.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (c) 2018 Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "optee_msg.h"
+#include "optee_private.h"
+
+/*
+ * Request and response definitions must be in sync with the secure side of
+ * OP-TEE.
+ */
+
+/* Request */
+struct rpmb_req {
+   u16 cmd;
+#define RPMB_CMD_DATA_REQ  0x00
+#define RPMB_CMD_GET_DEV_INFO  0x01
+   u16 dev_id;
+   u16 block_count;
+   /* Optional data frames (rpmb_data_frame) follow */
+};
+
+#define RPMB_REQ_DATA(req) ((void *)((struct rpmb_req *)(req) + 1))
+
+/* Response to device info request */
+struct rpmb_dev_info {
+   u8 cid[16];
+   u8 rpmb_size_mult;

[U-Boot] [PATCH v4 14/19] tee: add sandbox driver

[Jens Wiklander]

Adds a sandbox tee driver which emulates a generic TEE with the OP-TEE
AVB TA.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 drivers/tee/Kconfig   |  18 ++-
 drivers/tee/Makefile  |   1 +
 drivers/tee/optee/Kconfig |   2 +-
 drivers/tee/sandbox.c | 308 ++
 include/sandboxtee.h  |  21 +++
 5 files changed, 347 insertions(+), 3 deletions(-)
 create mode 100644 drivers/tee/sandbox.c
 create mode 100644 include/sandboxtee.h

diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index 835c256e9239..5c0c89043fac 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -1,8 +1,8 @@
 # Generic Trusted Execution Environment Configuration
 config TEE
bool "Trusted Execution Environment support"
-   depends on ARM && (ARM64 || CPU_V7A)
-   select ARM_SMCCC
+   depends on (ARM && (ARM64 || CPU_V7A)) || SANDBOX
+   select ARM_SMCCC if ARM
help
  This implements a generic interface towards a Trusted Execution
  Environment (TEE). A TEE is a trusted OS running in some secure
@@ -14,6 +14,20 @@ if TEE
 
 menu "TEE drivers"
 
+config SANDBOX_TEE
+   bool "Sandbox TEE emulator"
+   depends on SANDBOX
+   default y
+   help
+ This emulates a generic TEE needed for testing including the AVB
+ TA. The emulation provides all callbacks of a regular TEE and
+ supports session and shared memory management. The AVB TA is
+ emulated with rollback indexes and device lock-state, the state
+ of the TA is only kept in RAM and will be reset on each boot.
+ The emulation only supports one open session at a time.
+ Interaction from the U-Boot command line in possible via the
+ "avb" commands.
+
 source "drivers/tee/optee/Kconfig"
 
 endmenu
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index 19633b60f235..f72c68c09f33 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-y += tee-uclass.o
+obj-$(CONFIG_SANDBOX) += sandbox.o
 obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index dbfa7846a30f..d489834df926 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -10,7 +10,7 @@ config OPTEE
  handle Remote Procedure Calls (RPC) from OP-TEE needed to
  execute a service. For more information see: https://www.op-tee.org
 
-if OPTEE
+if OPTEE || SANDBOX
 
 menu "OP-TEE options"
 
diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
new file mode 100644
index ..10a1e8dffa69
--- /dev/null
+++ b/drivers/tee/sandbox.c
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Linaro Limited
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The sandbox tee driver tries to emulate a generic Trusted Exectution
+ * Environment (TEE) with the Trusted Application (TA) OPTEE_TA_AVB
+ * available.
+ */
+
+/**
+ * struct ta_entry - TA entries
+ * @uuid:  UUID of an emulated TA
+ * @open_session   Called when a session is openened to the TA
+ * @invoke_funcCalled when a function in the TA is to be 
invoked
+ *
+ * This struct is used to register TAs in this sandbox emulation of a TEE.
+ */
+struct ta_entry {
+   struct tee_optee_ta_uuid uuid;
+   u32 (*open_session)(uint num_params, struct tee_param *params);
+   u32 (*invoke_func)(u32 func, uint num_params, struct tee_param *params);
+};
+
+#ifdef CONFIG_OPTEE_TA_AVB
+static u32 get_attr(uint n, uint num_params, struct tee_param *params)
+{
+   if (n >= num_params)
+   return TEE_PARAM_ATTR_TYPE_NONE;
+
+   return params[n].attr;
+}
+
+static u32 check_params(u8 p0, u8 p1, u8 p2, u8 p3, uint num_params,
+   struct tee_param *params)
+{
+   u8 p[] = { p0, p1, p2, p3};
+   uint n;
+
+   for (n = 0; n < ARRAY_SIZE(p); n++)
+   if (p[n] != get_attr(n, num_params, params))
+   goto bad_params;
+
+   for (; n < num_params; n++)
+   if (get_attr(n, num_params, params))
+   goto bad_params;
+
+   return TEE_SUCCESS;
+
+bad_params:
+   printf("Bad param attrs\n");
+
+   return TEE_ERROR_BAD_PARAMETERS;
+}
+
+static u64 ta_avb_rollback_indexes[TA_AVB_MAX_ROLLBACK_LOCATIONS];
+static u32 ta_avb_lock_state;
+
+static u32 ta_avb_open_session(uint num_params, struct tee_param *params)
+{
+   /*
+* We don't expect additional parameters when opening a session to
+* this TA.
+*/
+   return check_params(TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
+   TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
+   num_params, params);
+}
+
+static u32 ta_av

[U-Boot] [PATCH v4 07/19] tee: add OP-TEE driver

[Jens Wiklander]

Adds a OP-TEE driver.

* Targets ARM and ARM64
* Supports using any U-Boot memory as shared memory
* Probes OP-TEE version using SMCs
* Uses OPTEE message protocol version 2 to communicate with secure world

Reviewed-by: Simon Glass 
Tested-by: Igor Opaniuk 
Signed-off-by: Jens Wiklander 
---
 drivers/tee/Kconfig  |  10 +
 drivers/tee/Makefile |   1 +
 drivers/tee/optee/Kconfig|  11 +
 drivers/tee/optee/Makefile   |   4 +
 drivers/tee/optee/core.c | 654 +++
 drivers/tee/optee/optee_msg.h| 425 +++
 drivers/tee/optee/optee_msg_supplicant.h | 240 +
 drivers/tee/optee/optee_private.h|  12 +
 drivers/tee/optee/optee_smc.h| 450 
 drivers/tee/optee/supplicant.c   |  93 
 10 files changed, 1900 insertions(+)
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_msg_supplicant.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/supplicant.c

diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index f3fc3c2ca790..835c256e9239 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -9,3 +9,13 @@ config TEE
  environment, for example, TrustZone on ARM cpus, or a separate
  secure co-processor etc. See also:
  https://en.wikipedia.org/wiki/Trusted_execution_environment
+
+if TEE
+
+menu "TEE drivers"
+
+source "drivers/tee/optee/Kconfig"
+
+endmenu
+
+endif
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index b6d8e16e6211..19633b60f235 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-y += tee-uclass.o
+obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
new file mode 100644
index ..7484e6fea114
--- /dev/null
+++ b/drivers/tee/optee/Kconfig
@@ -0,0 +1,11 @@
+# OP-TEE Trusted Execution Environment Configuration
+config OPTEE
+   bool "OP-TEE"
+   depends on ARM_SMCCC
+   help
+ This implements the OP-TEE Trusted Execution Environment (TEE)
+ driver. OP-TEE is a Trusted OS designed primarily to rely on the
+ ARM TrustZone(R) technology as the underlying hardware isolation
+ mechanism. This driver can request services from OP-TEE, but also
+ handle Remote Procedure Calls (RPC) from OP-TEE needed to
+ execute a service. For more information see: https://www.op-tee.org
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
new file mode 100644
index ..6148feb474a5
--- /dev/null
+++ b/drivers/tee/optee/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += core.o
+obj-y += supplicant.o
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
new file mode 100644
index ..726382da9bb8
--- /dev/null
+++ b/drivers/tee/optee/core.c
@@ -0,0 +1,654 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "optee_smc.h"
+#include "optee_msg.h"
+#include "optee_private.h"
+
+#define PAGELIST_ENTRIES_PER_PAGE \
+   ((OPTEE_MSG_NONCONTIG_PAGE_SIZE / sizeof(u64)) - 1)
+
+typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long,
+  unsigned long, unsigned long, unsigned long,
+  unsigned long, unsigned long,
+  struct arm_smccc_res *);
+
+struct optee_pdata {
+   optee_invoke_fn *invoke_fn;
+};
+
+struct rpc_param {
+   u32 a0;
+   u32 a1;
+   u32 a2;
+   u32 a3;
+   u32 a4;
+   u32 a5;
+   u32 a6;
+   u32 a7;
+};
+
+/**
+ * reg_pair_to_ptr() - Make a pointer of 2 32-bit values
+ * @reg0:  High bits of the pointer
+ * @reg1:  Low bits of the pointer
+ *
+ * Returns the combined result, note that if a pointer is 32-bit wide @reg0
+ * will be discarded.
+ */
+static void *reg_pair_to_ptr(u32 reg0, u32 reg1)
+{
+   return (void *)(ulong)(((u64)reg0 << 32) | reg1);
+}
+
+/**
+ * reg_pair_from_64() - Split a 64-bit value into two 32-bit values
+ * @reg0:  High bits of @val
+ * @reg1:  Low bits of @val
+ * @val:   The value to split
+ */
+static void reg_pair_from_64(u32 *reg0, u32 *reg1, u64 val)
+{
+   *reg0 = val >> 32;
+   *reg1 = val;
+}
+
+/**
+ * optee_alloc_and_init_page_list() - Provide page list of memory buffer
+ * @buf:   Start of buffer
+ * @len:   Length of buffer
+ * @phys_buf_ptr   

[U-Boot] [PATCH v4 08/19] Documentation: tee uclass and op-tee driver

[Jens Wiklander]

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 doc/README.tee | 112 +
 1 file changed, 112 insertions(+)
 create mode 100644 doc/README.tee

diff --git a/doc/README.tee b/doc/README.tee
new file mode 100644
index ..79e7996a6f5f
--- /dev/null
+++ b/doc/README.tee
@@ -0,0 +1,112 @@
+=
+TEE uclass
+=
+
+This document describes the TEE uclass in U-Boot
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This uclass deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between U-Boot and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=
+
+include/tee.h defines the generic interface to a TEE.
+
+A client finds the TEE device via tee_find_device(). Other important functions
+when interfacing with a TEE are:
+
+- tee_shm_alloc(), tee_shm_register() and tee_shm_free() to manage shared
+  memory objects often needed when communicating with the TEE.
+
+- tee_get_version() lets the client know which the capabilities of the TEE
+  device.
+
+- tee_open_session() opens a session to a Trusted Application
+
+- tee_invoke_func() invokes a function in a Trusted Application
+
+- tee_close_session() closes a session to a Trusted Application
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results.
+
+OP-TEE driver
+=
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+  which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+  to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+  separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+  range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture:
+
+   U-Boot  Secure world
+   ~~  
+ ++   +-+
+ | Client |   | Trusted |
+ ||   | Application |
+ ++   +-+
+   /\   /\
+   ||   ||
+   \/   \/
+ ++   +-+
+ | TEE|   | TEE Internal|
+ | uclass |   | API |
+ ++   +-+
+ | OP-TEE |   | OP-TEE  |
+ | driver |   | Trusted OS  |
+ ++---+-+
+ | OP-TEE MSG   |
+ |  SMCCC (OPTEE_SMC_CALL_*)|
+ +--+
+
+RPC (Remote Procedure Call) are requests from secure world to the driver.
+An RPC is identified by a special range of SMCCC return values from
+OPTEE_SMC_CALL_WITH_ARG.
+
+References
+==
+
+[1] https://github.com/OP-TEE/optee_os
+
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+
+[3] drivers/tee/optee/optee_smc.h
+
+[4] drivers/tee/optee/optee_msg.h
+
+[5] http://www.globalplatform.org/specificationsdevice.asp look for
+"TEE Client API Specification v1.0" and click download.
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 09/19] arm: dt: hikey: Add optee node

[Jens Wiklander]

Sync with 14e21cb8f811 ("arm64: dt: hikey: Add optee node"
from Linux kernel.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 arch/arm/dts/hi6220-hikey.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/hi6220-hikey.dts b/arch/arm/dts/hi6220-hikey.dts
index 818525197508..24f09257af00 100644
--- a/arch/arm/dts/hi6220-hikey.dts
+++ b/arch/arm/dts/hi6220-hikey.dts
@@ -31,6 +31,13 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
 };
 
  {
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 05/19] Add UCLASS_TEE for Trusted Execution Environment

[Jens Wiklander]

Adds a uclass to interface with a TEE (Trusted Execution Environment).

A TEE driver is a driver that interfaces with a trusted OS running in
some secure environment, for example, TrustZone on ARM cpus, or a
separate secure co-processor etc.

The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.

The over all design is based on the TEE subsystem in the Linux kernel,
tailored for U-Boot.

Reviewed-by: Simon Glass 
Tested-by: Igor Opaniuk 
Signed-off-by: Jens Wiklander 
---
 MAINTAINERS  |   6 +
 drivers/Kconfig  |   2 +
 drivers/Makefile |   1 +
 drivers/tee/Kconfig  |  11 ++
 drivers/tee/Makefile |   3 +
 drivers/tee/tee-uclass.c | 209 
 include/dm/uclass-id.h   |   1 +
 include/tee.h| 336 +++
 8 files changed, 569 insertions(+)
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/tee-uclass.c
 create mode 100644 include/tee.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8f237128b241..5b085ad3acd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -585,6 +585,12 @@ TQ GROUP
 S: Orphaned (Since 2016-02)
 T: git git://git.denx.de/u-boot-tq-group.git
 
+TEE
+M: Jens Wiklander 
+S: Maintained
+F: drivers/tee/
+F: include/tee.h
+
 UBI
 M: Kyungmin Park 
 M: Heiko Schocher 
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 56536c4b1915..1e44acb4835f 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -96,6 +96,8 @@ source "drivers/spmi/Kconfig"
 
 source "drivers/sysreset/Kconfig"
 
+source "drivers/tee/Kconfig"
+
 source "drivers/thermal/Kconfig"
 
 source "drivers/timer/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index d296354b3c01..17d6c0947a2f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -103,6 +103,7 @@ obj-y += smem/
 obj-y += soc/
 obj-$(CONFIG_REMOTEPROC) += remoteproc/
 obj-y += thermal/
+obj-$(CONFIG_TEE) += tee/
 obj-y += axi/
 
 obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
new file mode 100644
index ..f3fc3c2ca790
--- /dev/null
+++ b/drivers/tee/Kconfig
@@ -0,0 +1,11 @@
+# Generic Trusted Execution Environment Configuration
+config TEE
+   bool "Trusted Execution Environment support"
+   depends on ARM && (ARM64 || CPU_V7A)
+   select ARM_SMCCC
+   help
+ This implements a generic interface towards a Trusted Execution
+ Environment (TEE). A TEE is a trusted OS running in some secure
+ environment, for example, TrustZone on ARM cpus, or a separate
+ secure co-processor etc. See also:
+ https://en.wikipedia.org/wiki/Trusted_execution_environment
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
new file mode 100644
index ..b6d8e16e6211
--- /dev/null
+++ b/drivers/tee/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += tee-uclass.o
diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
new file mode 100644
index ..1bee54ebf4af
--- /dev/null
+++ b/drivers/tee/tee-uclass.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct tee_uclass_priv - information of a TEE, stored by the uclass
+ *
+ * @list_shm:  list of structe tee_shm representing memory blocks shared
+ * with the TEE.
+ */
+struct tee_uclass_priv {
+   struct list_head list_shm;
+};
+
+static const struct tee_driver_ops *tee_get_ops(struct udevice *dev)
+{
+   return device_get_ops(dev);
+}
+
+void tee_get_version(struct udevice *dev, struct tee_version_data *vers)
+{
+   tee_get_ops(dev)->get_version(dev, vers);
+}
+
+int tee_open_session(struct udevice *dev, struct tee_open_session_arg *arg,
+uint num_param, struct tee_param *param)
+{
+   return tee_get_ops(dev)->open_session(dev, arg, num_param, param);
+}
+
+int tee_close_session(struct udevice *dev, u32 session)
+{
+   return tee_get_ops(dev)->close_session(dev, session);
+}
+
+int tee_invoke_func(struct udevice *dev, struct tee_invoke_arg *arg,
+   uint num_param, struct tee_param *param)
+{
+   return tee_get_ops(dev)->invoke_func(dev, arg, num_param, param);
+}
+
+int __tee_shm_add(struct udevice *dev, ulong align, void *addr, ulong size,
+ u32 flags, struct tee_shm **shmp)
+{
+   struct tee_shm *shm;
+   void *p = addr;
+   int rc;
+
+   if (flags & TEE_SHM_ALLOC) {
+   if (align)
+   p = memalign(align, size);
+   else
+   p = malloc(size);
+   }
+   if (!p)
+   return -ENOMEM;
+
+   shm = calloc(1, sizeo

[U-Boot] [PATCH v4 06/19] dt/bindings: add bindings for optee

[Jens Wiklander]

Sync with c8bfafb15944 ("dt/bindings: add bindings for optee")
from Linux kernel.

Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 .../firmware/linaro,optee-tz.txt  | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 doc/device-tree-bindings/firmware/linaro,optee-tz.txt

diff --git a/doc/device-tree-bindings/firmware/linaro,optee-tz.txt 
b/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
new file mode 100644
index ..d38834c67dff
--- /dev/null
+++ b/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
@@ -0,0 +1,31 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip.
+
+We're using "linaro" as the first part of the compatible property for
+the reference implementation maintained by Linaro.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible : should contain "linaro,optee-tz"
+
+- method : The method of calling the OP-TEE Trusted OS. Permitted
+   values are:
+
+   "smc" : SMC #0, with the register assignments specified
+  in drivers/tee/optee/optee_smc.h
+
+   "hvc" : HVC #0, with the register assignments specified
+  in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 04/19] mmc: rpmb: add mmc_rpmb_route_frames()

[Jens Wiklander]

Adds mmc_rpmb_route_frames() to route RPMB data frames from/to an
external entity.

Tested-by: Igor Opaniuk 
Signed-off-by: Jens Wiklander 
---
 drivers/mmc/rpmb.c | 160 +
 include/mmc.h  |  19 ++
 2 files changed, 179 insertions(+)

diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index dfbdb0deb107..908f19208955 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -321,3 +321,163 @@ int mmc_rpmb_write(struct mmc *mmc, void *addr, unsigned 
short blk,
}
return i;
 }
+
+static int send_write_mult_block(struct mmc *mmc, const struct s_rpmb *frm,
+unsigned short cnt)
+{
+   struct mmc_cmd cmd = {
+   .cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK,
+   .resp_type = MMC_RSP_R1b,
+   };
+   struct mmc_data data = {
+   .src = (const void *)frm,
+   .blocks = cnt,
+   .blocksize = sizeof(*frm),
+   .flags = MMC_DATA_WRITE,
+   };
+
+   return mmc_send_cmd(mmc, , );
+}
+
+static int send_read_mult_block(struct mmc *mmc, struct s_rpmb *frm,
+   unsigned short cnt)
+{
+   struct mmc_cmd cmd = {
+   .cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK,
+   .resp_type = MMC_RSP_R1,
+   };
+   struct mmc_data data = {
+   .dest = (void *)frm,
+   .blocks = cnt,
+   .blocksize = sizeof(*frm),
+   .flags = MMC_DATA_READ,
+   };
+
+   return mmc_send_cmd(mmc, , );
+}
+
+static int rpmb_route_write_req(struct mmc *mmc, struct s_rpmb *req,
+   unsigned short req_cnt, struct s_rpmb *rsp,
+   unsigned short rsp_cnt)
+{
+   int ret;
+
+   /*
+* Send the write request.
+*/
+   ret = mmc_set_blockcount(mmc, req_cnt, true);
+   if (ret)
+   return ret;
+
+   ret = send_write_mult_block(mmc, req, req_cnt);
+   if (ret)
+   return ret;
+
+   /*
+* Read the result of the request.
+*/
+   ret = mmc_set_blockcount(mmc, 1, false);
+   if (ret)
+   return ret;
+
+   memset(rsp, 0, sizeof(*rsp));
+   rsp->request = cpu_to_be16(RPMB_REQ_STATUS);
+   ret = send_write_mult_block(mmc, rsp, 1);
+   if (ret)
+   return ret;
+
+   ret = mmc_set_blockcount(mmc, 1, false);
+   if (ret)
+   return ret;
+
+   return send_read_mult_block(mmc, rsp, 1);
+}
+
+static int rpmb_route_read_req(struct mmc *mmc, struct s_rpmb *req,
+  unsigned short req_cnt, struct s_rpmb *rsp,
+  unsigned short rsp_cnt)
+{
+   int ret;
+
+   /*
+* Send the read request.
+*/
+   ret = mmc_set_blockcount(mmc, 1, false);
+   if (ret)
+   return ret;
+
+   ret = send_write_mult_block(mmc, req, 1);
+   if (ret)
+   return ret;
+
+   /*
+* Read the result of the request.
+*/
+
+   ret = mmc_set_blockcount(mmc, rsp_cnt, false);
+   if (ret)
+   return ret;
+
+   return send_read_mult_block(mmc, rsp, rsp_cnt);
+}
+
+static int rpmb_route_frames(struct mmc *mmc, struct s_rpmb *req,
+unsigned short req_cnt, struct s_rpmb *rsp,
+unsigned short rsp_cnt)
+{
+   unsigned short n;
+
+   /*
+* If multiple request frames are provided, make sure that all are
+* of the same type.
+*/
+   for (n = 1; n < req_cnt; n++)
+   if (req[n].request != req->request)
+   return -EINVAL;
+
+   switch (be16_to_cpu(req->request)) {
+   case RPMB_REQ_KEY:
+   if (req_cnt != 1 || rsp_cnt != 1)
+   return -EINVAL;
+   return rpmb_route_write_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+   case RPMB_REQ_WRITE_DATA:
+   if (!req_cnt || rsp_cnt != 1)
+   return -EINVAL;
+   return rpmb_route_write_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+   case RPMB_REQ_WCOUNTER:
+   if (req_cnt != 1 || rsp_cnt != 1)
+   return -EINVAL;
+   return rpmb_route_read_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+   case RPMB_REQ_READ_DATA:
+   if (req_cnt != 1 || !req_cnt)
+   return -EINVAL;
+   return rpmb_route_read_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+   default:
+   debug("Unsupported message type: %d\n",
+ be16_to_cpu(req->request));
+   return -EINVAL;
+   }
+}
+
+int mmc_rpmb_route_frames(struct mmc *mmc, void *req, unsigned long reqlen,
+ void *rsp, unsigned long rsplen)
+{
+   /*
+* Whoever crafted the data supplied t

[U-Boot] [PATCH v4 03/19] cmd: avb: print error message if command fails

[Jens Wiklander]

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 cmd/avb.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/cmd/avb.c b/cmd/avb.c
index ca4b26d5d7b3..ff00be4cee38 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -35,6 +35,8 @@ int do_avb_init(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
if (avb_ops)
return CMD_RET_SUCCESS;
 
+   printf("Failed to initialize avb2\n");
+
return CMD_RET_FAILURE;
 }
 
@@ -65,6 +67,8 @@ int do_avb_read_part(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return CMD_RET_SUCCESS;
}
 
+   printf("Failed to read from partition\n");
+
return CMD_RET_FAILURE;
 }
 
@@ -108,6 +112,8 @@ int do_avb_read_part_hex(cmd_tbl_t *cmdtp, int flag, int 
argc,
return CMD_RET_SUCCESS;
}
 
+   printf("Failed to read from partition\n");
+
free(buffer);
return CMD_RET_FAILURE;
 }
@@ -138,6 +144,8 @@ int do_avb_write_part(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return CMD_RET_SUCCESS;
}
 
+   printf("Failed to write in partition\n");
+
return CMD_RET_FAILURE;
 }
 
@@ -161,6 +169,9 @@ int do_avb_read_rb(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
printf("Rollback index: %llx\n", rb_idx);
return CMD_RET_SUCCESS;
}
+
+   printf("Failed to read rollback index\n");
+
return CMD_RET_FAILURE;
 }
 
@@ -184,6 +195,8 @@ int do_avb_write_rb(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
AVB_IO_RESULT_OK)
return CMD_RET_SUCCESS;
 
+   printf("Failed to write rollback index\n");
+
return CMD_RET_FAILURE;
 }
 
@@ -210,6 +223,8 @@ int do_avb_get_uuid(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_SUCCESS;
}
 
+   printf("Failed to read UUID\n");
+
return CMD_RET_FAILURE;
 }
 
@@ -320,6 +335,8 @@ int do_avb_is_unlocked(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_SUCCESS;
}
 
+   printf("Can't determine device lock state.\n");
+
return CMD_RET_FAILURE;
 }
 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 02/19] cmd: avb read_rb: print rb_idx in hexadecimal

[Jens Wiklander]

Prior to this patch was do_avb_write_rb() reading supplied rb_idx as a
hexadecimal number while do_avb_read_rb() printed the read out rb_idx as
decimal number. For consistency change do_avb_read_rb() to print rb_idx
as a hexadecimal number too.

Reviewed-by: Simon Glass 
Reviewed-by: Igor Opaniuk 
Signed-off-by: Jens Wiklander 
---
 cmd/avb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/avb.c b/cmd/avb.c
index f045a0c64c4a..ca4b26d5d7b3 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -158,7 +158,7 @@ int do_avb_read_rb(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
if (avb_ops->read_rollback_index(avb_ops, index, _idx) ==
AVB_IO_RESULT_OK) {
-   printf("Rollback index: %llu\n", rb_idx);
+   printf("Rollback index: %llx\n", rb_idx);
return CMD_RET_SUCCESS;
}
return CMD_RET_FAILURE;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 01/19] dm: fdt: scan for devices under /firmware too

[Jens Wiklander]

Just as /chosen may contain devices /firmware may contain devices, scan
for devices under /firmware too.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 drivers/core/root.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/core/root.c b/drivers/core/root.c
index 72bcc7d7f2a3..0dca507e1187 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, const 
void *blob,
for (offset = fdt_first_subnode(blob, offset);
 offset > 0;
 offset = fdt_next_subnode(blob, offset)) {
-   /* "chosen" node isn't a device itself but may contain some: */
-   if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
-   pr_debug("parsing subnodes of \"chosen\"\n");
+   const char *node_name = fdt_get_name(blob, offset, NULL);
+
+   /*
+* The "chosen" and "firmware" nodes aren't devices
+* themselves but may contain some:
+*/
+   if (!strcmp(node_name, "chosen") ||
+   !strcmp(node_name, "firmware")) {
+   pr_debug("parsing subnodes of \"%s\"\n", node_name);
 
err = dm_scan_fdt_node(parent, blob, offset,
   pre_reloc_only);
@@ -286,8 +292,7 @@ static int dm_scan_fdt_node(struct udevice *parent, const 
void *blob,
err = lists_bind_fdt(parent, offset_to_ofnode(offset), NULL);
if (err && !ret) {
ret = err;
-   debug("%s: ret=%d\n", fdt_get_name(blob, offset, NULL),
- ret);
+   debug("%s: ret=%d\n", node_name, ret);
}
}
 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 00/19] AVB using OP-TEE

[Jens Wiklander]

Hi,

This adds support for storing AVB rollback indexes in the RPMB partition.
The RPMB partition (content and key) is managed by OP-TEE
(https://www.op-tee.org/) which is a secure OS leveraging ARM TrustZone.

The Linux kernel can already support OP-TEE with reading and updating
rollback indexes in the RPMB partition, the catch is that this is needed
before the kernel has booted.

The design here is the same as what is in the Linux kernel, with the
exception that the user space daemon tee-supplicant is integrated in the
OP-TEE driver here (drivers/tee/optee/supplicant.c) instead. A new uclass
(UCLASS_TEE) is introduced to provide an abstraction for interfacing with a
Trusted Execution Environment (TEE). There's also the OP-TEE driver using
UCLASS_TEE for registration.

A Trusted Application (TA) interface is added to be used by the AVB verify
functions which are updated accordingly. The TA is managed by OP-TEE and is
executed in a secure TrustZone protected environment.

The header files drivers/tee/optee/optee_{msg,msg_supplicant,smc}.h and
include/tee/optee_ta_avb.h are copied from
https://github.com/OP-TEE/optee_os/tree/master more or less unmodified.
They may need to be updated from time to time in order to support new
features.

In MMC there's a new function, mmc_rpmb_route_frames(), which as the name
suggests is used to route RPMB frames to/from the MMC. This saves OP-TEE
from implementing an MMC driver which would need to share resources with
its counterpart here in U-Boot.

This was tested on a Hikey (Kirin 620) board.

I've added myself as maintainer of the TEE stuff.

changes in v4:
* Addressed review comments from Simon Glass
* Rebased on v2018.09
* "avb_verify: bugfix avb_ops_free() skipping free" removed due to the rebase
* Commits "dt/bindings: add bindings for optee",
  "sandbox: imply CONFIG_TEE (TEE uclass)",
  "tee: add sandbox driver",
  "avb_verify: support using OP-TEE TA AVB",
  "test_avb: Update pymark.buildconfigspec information for the AVB tests",
  "Kconfig: sandbox: enable cmd_avb and dependencies",
  Reviewed-by: Simon Glass 
* Added descriptions of additional structs and functions
* In commit "avb_verify: support sandbox configuration" avoid the
  #ifdef CONFIG_SANDBOX in get_sector_buf() as suggested by Simon.

changes in v3:
* Addressed review comments from Simon Glass
* A few new patches
  - "avb_verify: bugfix avb_ops_free() skipping free"
  - "tee: add sandbox driver"
  - "test_avb: Update pymark.buildconfigspec information for the AVB tests"
  - "avb_verify: support sandbox configuration"
  - "Kconfig: sandbox: enable cmd_avb and dependencies"
* "sandbox: imply CONFIG_TEE (TEE uclass)", replacing
  "configs: sandbox: enable CONFIG_TEE (TEE uclass)"
* Moved sandbox driver to drivers/tee and added code to emulate the AVB TA
* Enabled a few AVB tests (test/py/tests/test_avb.py) for sandbox
* Bugfix tee_find_device()
* Commits "dm: fdt: scan for devices under /firmware too",
  "cmd: avb read_rb: print rb_idx in hexadecimal",
  "cmd: avb: print error message if command fails",
  "Add UCLASS_TEE for Trusted Execution Environment",
  "tee: add OP-TEE driver",
  "Documentation: tee uclass and op-tee driver",
  "test: tee: test TEE uclass",
  "arm: dt: hikey: Add optee node" and
  "sandbox: dt: add sandbox_tee node"
  Reviewed-by: Simon Glass 

changes in v2:
* Added sandbox driver and a test in test/dm for the new TEE uclass:
  Commit ("test: tee: test TEE uclass") and the enabling commits
  ("sandbox: dt: add sandbox_tee node") and
  ("configs: sandbox: enable CONFIG_TEE (TEE uclass)")
* Added descriptions of exported structs and functions
* Added documentation for the TEE uclass and the OP-TEE driver with
  the new commit ("Documentation: tee uclass and op-tee driver")
* Added documentation for the changes in avb_verify
* Addressed review comments from Simon Glass
* Added the commit ("cmd: avb: print error message if command fails")
* Made a few functions static in the OP-TEE driver
* Commit ("cmd: avb read_rb: print rb_idx in hexadecimal") and
  ("tee: optee: support AVB trusted application");
  Reviewed-by: Igor Opaniuk 

Thanks,
Jens

Jens Wiklander (19):
  dm: fdt: scan for devices under /firmware too
  cmd: avb read_rb: print rb_idx in hexadecimal
  cmd: avb: print error message if command fails
  mmc: rpmb: add mmc_rpmb_route_frames()
  Add UCLASS_TEE for Trusted Execution Environment
  dt/bindings: add bindings for optee
  tee: add OP-TEE driver
  Documentation: tee uclass and op-tee driver
  arm: dt: hikey: Add optee node
  optee: support routing of rpmb data frames to mmc
  tee: optee: support AVB trusted application
  sandbox: dt: add sandbox_tee node
  sandbox

Re: [U-Boot] [PATCH v3 19/20] avb_verify: support sandbox configuration

[Jens Wiklander]

Hi Simon,

On Fri, Sep 14, 2018 at 12:54 PM, Simon Glass  wrote:
> Hi Jens,
>
> On 3 September 2018 at 16:47, Jens Wiklander  
> wrote:
>> With CONFIG_SANDBOX malloc a buffer in get_sector_buf() and return that
>> instead of returning CONFIG_FASTBOOT_BUF_ADDR since there's no such
>> buffer reserved.
>>
>> Signed-off-by: Jens Wiklander 
>> ---
>>  include/avb_verify.h | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/include/avb_verify.h b/include/avb_verify.h
>> index a532a2331aea..7b95409d247e 100644
>> --- a/include/avb_verify.h
>> +++ b/include/avb_verify.h
>> @@ -76,7 +76,16 @@ static inline size_t get_sector_buf_size(void)
>>
>>  static inline void *get_sector_buf(void)
>>  {
>> +#ifdef CONFIG_SANDBOX
>> +   static void *p;
>> +
>> +   if (!p)
>> +   p = avb_malloc_(get_sector_buf_size());
>> +
>> +   return p;
>> +#else
>> return (void *)CONFIG_FASTBOOT_BUF_ADDR;
>
> Can you not define this on sandbox? We don't want sandbox to have
> special-case code if we can avoid it.
>
> If you do define it, you should change the code to:
>
> return map_sysmem(CONFIG_..., size);
>
> which works on sandbox and other archs too.

Thanks, I'll use that.

--
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 17/20] avb_verify: support using OP-TEE TA AVB

[Jens Wiklander]

On Fri, Sep 14, 2018 at 12:54 PM, Simon Glass  wrote:
> On 3 September 2018 at 16:47, Jens Wiklander  
> wrote:
>> With CONFIG_OPTEE_TA_AVB use the trusted application AVB provided by
>> OP-TEE to manage rollback indexes and device lock status.
>
> Should this be device-lock status?

Yes, I'll fix.

>
>>
>> Signed-off-by: Jens Wiklander 
>> ---
>>  common/avb_verify.c  | 118 ++-
>>  doc/README.avb2  |  13 +
>>  include/avb_verify.h |   4 ++
>>  3 files changed, 134 insertions(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 

Thanks,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 15/20] tee: add sandbox driver

[Jens Wiklander]

Hi Simon,

I have one question inline below.

On Fri, Sep 14, 2018 at 12:53 PM, Simon Glass  wrote:
> Hi Jens,
>
> On 3 September 2018 at 16:47, Jens Wiklander  
> wrote:
>> Adds a sandboxtee driver which emulates a generic TEE with the OP-TEE
>
> sandbox tee
>
>> AVB TA.
>>
>> Signed-off-by: Jens Wiklander 
>> ---
>>  drivers/tee/Kconfig   |  12 +-
>>  drivers/tee/Makefile  |   1 +
>>  drivers/tee/optee/Kconfig |   2 +-
>>  drivers/tee/sandbox.c | 299 ++
>>  include/sandboxtee.h  |  15 ++
>>  5 files changed, 326 insertions(+), 3 deletions(-)
>>  create mode 100644 drivers/tee/sandbox.c
>>  create mode 100644 include/sandboxtee.h
>
> Reviewed-by: Simon Glass 
>
> nits below.
>
>>
>> diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
>> index 835c256e9239..4697b80913d6 100644
>> --- a/drivers/tee/Kconfig
>> +++ b/drivers/tee/Kconfig
>> @@ -1,8 +1,8 @@
>>  # Generic Trusted Execution Environment Configuration
>>  config TEE
>> bool "Trusted Execution Environment support"
>> -   depends on ARM && (ARM64 || CPU_V7A)
>> -   select ARM_SMCCC
>> +   depends on (ARM && (ARM64 || CPU_V7A)) || SANDBOX
>> +   select ARM_SMCCC if ARM
>> help
>>   This implements a generic interface towards a Trusted Execution
>>   Environment (TEE). A TEE is a trusted OS running in some secure
>> @@ -14,6 +14,14 @@ if TEE
>>
>>  menu "TEE drivers"
>>
>> +config SANDBOX_TEE
>> +   bool "Sandbox TEE emulator"
>> +   depends on SANDBOX
>> +   default y
>> +   help
>> + This emulates a generic TEE needed for testing including the AVB
>> + TA.
>
> Can you please expand this? What features does it implement? How do
> you access it from the U-Boot command line?

I'll expand it.

>
>> +
>>  source "drivers/tee/optee/Kconfig"
>>
>>  endmenu
>> diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
>> index 19633b60f235..f72c68c09f33 100644
>> --- a/drivers/tee/Makefile
>> +++ b/drivers/tee/Makefile
>> @@ -1,4 +1,5 @@
>>  # SPDX-License-Identifier: GPL-2.0+
>>
>>  obj-y += tee-uclass.o
>> +obj-$(CONFIG_SANDBOX) += sandbox.o
>>  obj-$(CONFIG_OPTEE) += optee/
>> diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
>> index dbfa7846a30f..d489834df926 100644
>> --- a/drivers/tee/optee/Kconfig
>> +++ b/drivers/tee/optee/Kconfig
>> @@ -10,7 +10,7 @@ config OPTEE
>>   handle Remote Procedure Calls (RPC) from OP-TEE needed to
>>   execute a service. For more information see: https://www.op-tee.org
>>
>> -if OPTEE
>> +if OPTEE || SANDBOX
>>
>>  menu "OP-TEE options"
>>
>> diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
>> new file mode 100644
>> index ..cd073497615f
>> --- /dev/null
>> +++ b/drivers/tee/sandbox.c
>> @@ -0,0 +1,299 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2018 Linaro Limited
>> + */
>> +#include 
>> +#include 
>> +#include 
>
> Could this go in asm/ ?

I don't understand. What should go into asm/ and which directory is that?

>
>> +#include 
>> +#include 
>> +
>> +/*
>> + * The sandbox tee driver tries to emulate a generic TEE with the TA
>> + * OPTEE_TA_AVB available.
>
> What is TEE?
>
> What is TA?
>
> Please expand out the names once in this comment so people can see
> immediately what you are referring to.
>
>> + */
>> +
>
>
>
>> +struct ta_entry {
>
> What is this struct for? Please add a comment

OK

>
>> +   struct tee_optee_ta_uuid uuid;
>> +   u32 (*open_session)(uint num_params, struct tee_param *params);
>> +   u32 (*invoke_func)(u32 func, uint num_params, struct tee_param 
>> *params);
>> +};
>> +
>> +#ifdef CONFIG_OPTEE_TA_AVB
>> +static u32 get_attr(uint n, uint num_params, struct tee_param *params)
>> +{
>> +   if (n >= num_params)
>> +   return TEE_PARAM_ATTR_TYPE_NONE;
>> +
>> +   return params[n].attr;
>> +}
>> +
>> +static u32 check_params(u8 p0, u8 p1, u8 p2, u8 p3, uint num_params,
>> +   struct tee_param *params)
>> +{
>> +   u8 p[] = { p0, p1, p2, p3};
>> +   uint n;
>> +
>> +   for (n = 0; n < A

Re: [U-Boot] [PATCH v3 05/20] mmc: rpmb: add mmc_rpmb_route_frames()

[Jens Wiklander]

Hi Simon,

On Fri, Sep 14, 2018 at 12:53 PM, Simon Glass  wrote:
> Hi Jens,
>
> On 3 September 2018 at 16:46, Jens Wiklander  
> wrote:
>> Adds mmc_rpmb_route_frames() to route RPMB data frames from/to an
>> external entity.
>>
>> Tested-by: Igor Opaniuk 
>> Signed-off-by: Jens Wiklander 
>> ---
>>  drivers/mmc/rpmb.c | 160 +
>>  include/mmc.h  |   2 +
>>  2 files changed, 162 insertions(+)
>>
>
> [..]
>
>> diff --git a/include/mmc.h b/include/mmc.h
>> index df4255b828a7..d6e02af4edea 100644
>> --- a/include/mmc.h
>> +++ b/include/mmc.h
>> @@ -748,6 +748,8 @@ int mmc_rpmb_read(struct mmc *mmc, void *addr, unsigned 
>> short blk,
>>   unsigned short cnt, unsigned char *key);
>>  int mmc_rpmb_write(struct mmc *mmc, void *addr, unsigned short blk,
>>unsigned short cnt, unsigned char *key);
>> +int mmc_rpmb_route_frames(struct mmc *mmc, void *req, unsigned long reqlen,
>> + void *rsp, unsigned long rsplen);
>
> Please can you add a full comment to this function? All header-file
> functions should be commented.

I'll fix.

Thanks,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] fdt: fdtdec_setup_memory_banksize() use livetree

[Jens Wiklander]

Hi Simon,

On Tue, Sep 18, 2018 at 4:05 AM, Simon Glass  wrote:
> Hi Jen,
>
> On 17 August 2018 at 14:48, Simon Glass  wrote:
>>
>> On 10 August 2018 at 06:54, Jens Wiklander  wrote:
>> > Converts fdtdec_setup_memory_banksize() to use ofnode functions instead.
>> >
>> > Signed-off-by: Jens Wiklander 
>> > ---
>> >  lib/fdtdec.c | 46 +-
>> >  1 file changed, 21 insertions(+), 25 deletions(-)
>> >
>>
>> Reviewed-by: Simon Glass 
>
>
> Can you please rebase this on u-boot-dm/testing and resent? It seems
> to conflict with an existing patch.

I'm sorry, missed this one. It seems it's already been done by now.

Thanks,
Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 18/20] test_avb: Update pymark.buildconfigspec information for the AVB tests

[Jens Wiklander]

Update the pymark.buildconfigspec to depend on 'cmd_mmc' in addition to
'cmd_avb' for those tests that needs more a more complete MMC
implementation or the "mmc" command.

Signed-off-by: Jens Wiklander 
---
 test/py/tests/test_avb.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index 7996e4845db3..9683fd80d074 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -23,7 +23,7 @@ mmc_dev = 1
 temp_addr = 0x9000
 temp_addr2 = 0x90002000
 
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
 def test_avb_verify(u_boot_console):
 """Run AVB 2.0 boot verification chain with avb subset of commands
 """
@@ -36,7 +36,7 @@ def test_avb_verify(u_boot_console):
 assert response.find(success_str)
 
 
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
 def test_avb_mmc_uuid(u_boot_console):
 """Check if 'avb get_uuid' works, compare results with
 'part list mmc 1' output
@@ -78,6 +78,7 @@ def test_avb_read_rb(u_boot_console):
 assert response == ''
 
 response = u_boot_console.run_command('avb read_rb 1')
+assert response == 'Rollback index: 0'
 
 
 @pytest.mark.buildconfigspec('cmd_avb')
@@ -89,9 +90,10 @@ def test_avb_is_unlocked(u_boot_console):
 assert response == ''
 
 response = u_boot_console.run_command('avb is_unlocked')
+assert response == 'Unlocked = 1'
 
 
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
 def test_avb_mmc_read(u_boot_console):
 """Test mmc read operation
 """
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 20/20] Kconfig: sandbox: enable cmd_avb and dependencies

[Jens Wiklander]

Enables cmd_avb and its dependencies need to run the AVB tests.

Signed-off-by: Jens Wiklander 
---
 arch/Kconfig | 4 
 drivers/fastboot/Kconfig | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 8f10f3fc06e8..543362578f50 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -92,6 +92,10 @@ config SANDBOX
imply LZMA
imply SCSI
imply TEE
+   imply AVB_VERIFY
+   imply LIBAVB
+   imply CMD_AVB
+   imply UDP_FUNCTION_FASTBOOT
 
 config SH
bool "SuperH architecture"
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index bc25ea1d9c7a..d63ecdd27e4b 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -35,6 +35,7 @@ config FASTBOOT_BUF_ADDR
ROCKCHIP_RK3399
default 0x28 if ROCKCHIP_RK3368
default 0x10 if ARCH_ZYNQMP
+   default 0 if SANDBOX
help
  The fastboot protocol requires a large memory buffer for
  downloads. Define this to the starting RAM address to use for
@@ -45,6 +46,7 @@ config FASTBOOT_BUF_SIZE
default 0x800 if ARCH_ROCKCHIP
default 0x600 if ARCH_ZYNQMP
default 0x200 if ARCH_SUNXI
+   default 0x8192 if SANDBOX
default 0x700
help
  The fastboot protocol requires a large memory buffer for
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 16/20] test: tee: test TEE uclass

[Jens Wiklander]

Tests the TEE uclass with a sandbox tee driver.

Reviewed-by: Simon Glass 
Signed-off-by: Jens Wiklander 
---
 test/dm/Makefile |  1 +
 test/dm/tee.c| 98 
 2 files changed, 99 insertions(+)
 create mode 100644 test/dm/tee.c

diff --git a/test/dm/Makefile b/test/dm/Makefile
index d2ed96c61533..272374b92fb0 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -44,4 +44,5 @@ obj-$(CONFIG_DM_VIDEO) += video.o
 obj-$(CONFIG_ADC) += adc.o
 obj-$(CONFIG_SPMI) += spmi.o
 obj-$(CONFIG_WDT) += wdt.o
+obj-$(CONFIG_TEE) += tee.o
 endif
diff --git a/test/dm/tee.c b/test/dm/tee.c
new file mode 100644
index ..ab1c7da9d2d3
--- /dev/null
+++ b/test/dm/tee.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Linaro Limited
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int open_session(struct udevice *dev, u32 *session)
+{
+   struct tee_open_session_arg arg;
+   const struct tee_optee_ta_uuid uuid = TA_AVB_UUID;
+   int rc;
+
+   memset(, 0, sizeof(arg));
+   tee_optee_ta_uuid_to_octets(arg.uuid, );
+   rc = tee_open_session(dev, , 0, NULL);
+   if (rc)
+   return rc;
+   if (arg.ret)
+   return -EIO;
+   *session = arg.session;
+
+   return 0;
+}
+
+static int invoke_func(struct udevice *dev, u32 session)
+{
+   struct tee_param param = { .attr = TEE_PARAM_ATTR_TYPE_VALUE_OUTPUT };
+   struct tee_invoke_arg arg;
+
+   memset(, 0, sizeof(arg));
+   arg.session = session;
+   arg.func = TA_AVB_CMD_READ_LOCK_STATE;
+
+   if (tee_invoke_func(dev, , 1, ) || arg.ret)
+   return -1;
+
+   return 0;
+}
+
+static int match(struct tee_version_data *vers, const void *data)
+{
+   return vers->gen_caps & TEE_GEN_CAP_GP;
+}
+
+static int dm_test_tee(struct unit_test_state *uts)
+{
+   struct tee_version_data vers;
+   struct udevice *dev;
+   struct sandbox_tee_state *state;
+   u32 session;
+   int rc;
+   u8 data[128];
+   struct tee_shm *reg_shm;
+   struct tee_shm *alloc_shm;
+
+   dev = tee_find_device(NULL, match, NULL, );
+   ut_assert(dev);
+   state = dev_get_priv(dev);
+   ut_assert(!state->session);
+
+   rc = open_session(dev, );
+   ut_assert(!rc);
+   ut_assert(session == state->session);
+
+   rc = invoke_func(dev, session);
+   ut_assert(!rc);
+
+   rc = tee_close_session(dev, session);
+   ut_assert(!rc);
+   ut_assert(!state->session);
+
+   ut_assert(!state->num_shms);
+   rc = tee_shm_register(dev, data, sizeof(data), 0, _shm);
+   ut_assert(!rc);
+   ut_assert(state->num_shms == 1);
+
+   rc = tee_shm_alloc(dev, 256, 0, _shm);
+   ut_assert(!rc);
+   ut_assert(state->num_shms == 2);
+
+   ut_assert(tee_shm_is_registered(reg_shm, dev));
+   ut_assert(tee_shm_is_registered(alloc_shm, dev));
+
+   tee_shm_free(reg_shm);
+   tee_shm_free(alloc_shm);
+   ut_assert(!state->num_shms);
+
+   return 0;
+}
+
+DM_TEST(dm_test_tee, DM_TESTF_SCAN_FDT);
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 19/20] avb_verify: support sandbox configuration

[Jens Wiklander]

With CONFIG_SANDBOX malloc a buffer in get_sector_buf() and return that
instead of returning CONFIG_FASTBOOT_BUF_ADDR since there's no such
buffer reserved.

Signed-off-by: Jens Wiklander 
---
 include/avb_verify.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/avb_verify.h b/include/avb_verify.h
index a532a2331aea..7b95409d247e 100644
--- a/include/avb_verify.h
+++ b/include/avb_verify.h
@@ -76,7 +76,16 @@ static inline size_t get_sector_buf_size(void)
 
 static inline void *get_sector_buf(void)
 {
+#ifdef CONFIG_SANDBOX
+   static void *p;
+
+   if (!p)
+   p = avb_malloc_(get_sector_buf_size());
+
+   return p;
+#else
return (void *)CONFIG_FASTBOOT_BUF_ADDR;
+#endif
 }
 
 static inline bool is_buf_unaligned(void *buffer)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot