Tee-dev

tee-dev@lists.linaro.org

292 discussions

[PATCH v2 1/1] tee: add cancellation support to client interface

by Igor Opaniuk

Add support of cancellation request to the TEE kernel internal client interface. Can be used by software TPM drivers, that leverage TEE under the hood (for instance TPM2.0 mobile profile), for requesting cancellation of time-consuming operations (RSA key-pair generation etc.). Signed-off-by: Igor Opaniuk <igor.opaniuk(a)linaro.org> --- v2: - use tee_ioctl_cancel_arg to provide session and cancel_id - fix tee_client_cancel_req function description header drivers/tee/tee_core.c | 10 ++++++++++ include/linux/tee_drv.h | 12 ++++++++++++ 2 files changed, 22 insertions(+) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 7b2bb4c..1148175 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1027,6 +1027,16 @@ int tee_client_invoke_func(struct tee_context *ctx, } EXPORT_SYMBOL_GPL(tee_client_invoke_func); +int tee_client_cancel_req(struct tee_context *ctx, + struct tee_ioctl_cancel_arg *arg) +{ + if (!ctx->teedev->desc->ops->cancel_req) + return -EINVAL; + return ctx->teedev->desc->ops->cancel_req(ctx, arg->cancel_id, + arg->session); +} +EXPORT_SYMBOL_GPL(tee_client_cancel_req); + static int __init tee_init(void) { int rc; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 6cfe058..177016e 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -526,6 +526,18 @@ int tee_client_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param); +/** + * tee_client_cancel_req() - Request cancellation of the previous open-session + * or invoke-command operations in a Trusted Application + * @ctx: TEE Context + * @arg: Cancellation arguments, see description of + * struct tee_ioctl_cancel_arg + * + * Returns < 0 on error else 0 if the cancellation was successfully requested. + */ +int tee_client_cancel_req(struct tee_context *ctx, + struct tee_ioctl_cancel_arg *arg); + static inline bool tee_param_is_memref(struct tee_param *param) { switch (param->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK) { -- 2.7.4

6 years, 4 months

Re: [Tee-dev] [U-Boot] [RFC] efi_loader: EFI variables

by Sumit Garg

+ tee-dev ML On Tue, 12 Feb 2019 at 17:36, Alexander Graf <agraf(a)suse.de> wrote: > > On 02/12/2019 12:34 PM, Heinrich Schuchardt wrote: > > On 2/12/19 10:49 AM, Alexander Graf wrote: > >> On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote: > >>> Hello Alex, hello Takahiro, > >>> > >>> this morning I met Daniel Thompson of Linaro. He thinks it would be > >>> quite valuable if U-Boot would at least offer read access to EFI > >>> variables at runtime. > >>> > >>> I think what it takes is only a RAM buffer that we put between our > >>> current storage backend (i.e. synchronization with U-Boot variables) > >>> and the API implementation. > >>> > >>> We will need such a buffer anyway for non-permanent variables once we > >>> have a SPI flash storage. > >> I think slowly we need to take a critical design decision: Do we want to > >> be in the business of managing runtime UEFI variables? > >> > >> I don't have a fully cohesive answer to that yet. My gut feeling tells > >> me, that runtime variables would be much better off if they lived in > >> TrustZone. That way we don't have to play relocation tricks, and devices > >> that give you persistency are owned by the secure world anyway, so there > >> is no weird intersection between OS and RTS. > >> > >> So maybe the path forward would be to implement variable services in ATF > >> (or OP-TEE rather I suppose) and just provide shim stubs to communicate > >> with them from runtime services? That would keep all the variable logic > >> platform agnostic, and we would not have to jump through weird hoops > >> with DM. > > U-Boot' major asset are the many boards supported by drivers. Does ATF > > or OP-TEE have drivers for SPI? > > > > Or is your idea that U-Boot would provide a module that is set up as a > > trusted driver or trusted app, cf. > > https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-o… > > I think it's perfectly possible to build a special OP-TEE U-Boot target > that can then reuse its drivers, similar to Simon's idea. But we should > probably not try to target RTS with that, but only secure enclaves. > One of OP-TEE design goals [1] being: Small footprint - the TEE should remain small enough to reside in a reasonable amount of on-chip memory as found on Arm based systems. I think this was one of main reason to have tee-supplicant infrastructure in normal world to reuse drivers and keep small footprint of OP-TEE. So if we build a special OP-TEE u-boot target and link it with optee-os as part of secure enclave then I am not sure how it will align with above design goal. [1] https://optee.readthedocs.io/general/about.html -Sumit > > Alex > > _______________________________________________ > U-Boot mailing list > U-Boot(a)lists.denx.de > https://lists.denx.de/listinfo/u-boot

6 years, 4 months

[PATCH v6 0/4] Introduce TEE bus driver framework

by Sumit Garg

This series introduces a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/ services. Patch #1 adds TEE bus concept where devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. This concept also allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Patch #2 adds supp_nowait flag for non-blocking requests arising via TEE internal client interface. Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/services for TEE bus. Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver. On ARM SoC's with TrustZone enabled, peripherals like entropy sources might not be accessible to normal world (linux in this case) and rather accessible to secure world (OP-TEE in this case) only. So this driver aims to provides a generic interface to OP-TEE based random number generator service. Example case is Developerbox based on Socionext's Synquacer SoC [1] which provides 7 thermal sensors accessible from secure world only which could be used as entropy sources (thermal/measurement noise). [1] https://www.96boards.org/product/developerbox/ Changes in v6: 1. Incorporate some nitpicks in patch #1 and #3. 2. Bundle all statics in a data structure in patch #4 and use dev_* instead of pr_*. 3. Add reviewed-by tags for patch #1, #2 and #3. Changes in v5: 1. Add support in module device table for TEE bus devices. 2. Correct license for optee-rng module. Changes in v4: 1. Use typedef instead of single member tee_client_device_id struct. 2. Incorporate TEE bus nitpicks. Changes in v3: 1. Fixed bus error path in Patch #1. 2. Reversed order of Patch #2 and #3. 3. Fixed miscellaneous syntax comments and memory leak. 4. Added comments in Patch #2 for supp_nowait flag. Changes in v2: Based on review comments, the scope of this series has increased as follows: 1. Added TEE bus driver framework. 2. Added OP-TEE based device enumeration. 3. Register optee-rng driver as TEE bus driver. 4. Removed DT dependency for optee-rng device UUID. 5. Added supp_nowait flag. Sumit Garg (4): tee: add bus driver framework for TEE based devices tee: add supp_nowait flag in tee_context struct tee: optee: add TEE bus device enumeration support hwrng: add OP-TEE based rng driver MAINTAINERS | 5 + drivers/char/hw_random/Kconfig | 15 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/optee-rng.c | 298 +++++++++++++++++++++++++++++++++++++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 4 + drivers/tee/optee/device.c | 155 +++++++++++++++++++ drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/supp.c | 10 +- drivers/tee/tee_core.c | 67 ++++++++- include/linux/mod_devicetable.h | 9 ++ include/linux/tee_drv.h | 38 ++++- scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 19 +++ 14 files changed, 622 insertions(+), 6 deletions(-) create mode 100644 drivers/char/hw_random/optee-rng.c create mode 100644 drivers/tee/optee/device.c -- 2.7.4

6 years, 4 months

[PATCH 1/1] toolchain: update AArch32/AArch64 toolchain to 8-2-2019.01

by Joakim Bech

Tested with OP-TEE [1] using GCC 8.2 2019.01 for both AArch32 (QEMU Armv7-A, gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabihf [2]) and with AArch64 (QEMU Armv8-A, gcc-arm-8.2-2019.01-x86_64-aarch64-linux-gnu [2]) which has gotten TUI mode re-enabled [3]. [1] https://github.com/OP-TEE [2] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads [3] https://bugs.linaro.org/show_bug.cgi?id=4130 Signed-off-by: Joakim Bech <joakim.bech(a)linaro.org> --- package/linux-headers/Config.in.host | 4 ++++ toolchain/Config.in | 5 +++++ .../toolchain-external-arm-aarch64/Config.in | 4 ++-- .../toolchain-external/toolchain-external-arm-arm/Config.in | 4 ++-- .../toolchain-external-custom/Config.in.options | 4 ++++ 5 files changed, 17 insertions(+), 4 deletions(-) diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host index a6055e75b9..fd0cef8b21 100644 --- a/package/linux-headers/Config.in.host +++ b/package/linux-headers/Config.in.host @@ -51,6 +51,10 @@ config BR2_KERNEL_HEADERS_4_20 bool "Linux 4.20.x kernel headers" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 +config BR2_KERNEL_HEADERS_5_00 + bool "Linux 5.00.x kernel headers" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 + config BR2_KERNEL_HEADERS_VERSION bool "Manually specified Linux version" help diff --git a/toolchain/Config.in b/toolchain/Config.in index baf192c936..fd197f2407 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -374,10 +374,15 @@ config BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 bool select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_19 +config BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 + bool + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 + # This order guarantees that the highest version is set, as kconfig # stops affecting a value on the first matching default. config BR2_TOOLCHAIN_HEADERS_AT_LEAST string + default "5.00" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 default "4.20" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 default "4.19" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_19 default "4.18" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_18 diff --git a/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in b/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in index fbb5e025e8..279cb88f31 100644 --- a/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in +++ b/toolchain/toolchain-external/toolchain-external-arm-aarch64/Config.in @@ -1,5 +1,5 @@ config BR2_TOOLCHAIN_EXTERNAL_ARM_AARCH64 - bool "Arm AArch64 2018.11" + bool "Arm AArch64 2019.01" depends on BR2_aarch64 depends on BR2_HOSTARCH = "x86_64" depends on !BR2_STATIC_LIBS @@ -7,7 +7,7 @@ config BR2_TOOLCHAIN_EXTERNAL_ARM_AARCH64 select BR2_TOOLCHAIN_HAS_SSP select BR2_INSTALL_LIBSTDCPP select BR2_TOOLCHAIN_HAS_NATIVE_RPC - select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 select BR2_TOOLCHAIN_GCC_AT_LEAST_8 select BR2_TOOLCHAIN_HAS_FORTRAN help diff --git a/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in b/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in index 0449737889..69c2f7425e 100644 --- a/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in +++ b/toolchain/toolchain-external/toolchain-external-arm-arm/Config.in @@ -4,7 +4,7 @@ comment "Arm toolchains available for Cortex-A + EABIhf" depends on !BR2_STATIC_LIBS config BR2_TOOLCHAIN_EXTERNAL_ARM_ARM - bool "Arm ARM 2018.11" + bool "Arm ARM 2019.01" depends on BR2_arm depends on BR2_ARM_CPU_ARMV7A || BR2_ARM_CPU_ARMV8A depends on BR2_HOSTARCH = "x86_64" @@ -14,7 +14,7 @@ config BR2_TOOLCHAIN_EXTERNAL_ARM_ARM select BR2_TOOLCHAIN_HAS_SSP select BR2_TOOLCHAIN_HAS_NATIVE_RPC select BR2_INSTALL_LIBSTDCPP - select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 select BR2_TOOLCHAIN_GCC_AT_LEAST_8 select BR2_TOOLCHAIN_HAS_FORTRAN help diff --git a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options index 08a79ee4d9..48eb1ea080 100644 --- a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options +++ b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options @@ -123,6 +123,10 @@ choice m = ( LINUX_VERSION_CODE >> 8 ) & 0xFF p = ( LINUX_VERSION_CODE >> 0 ) & 0xFF +config BR2_TOOLCHAIN_EXTERNAL_HEADERS_5_00 + bool "5.00.x" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_00 + config BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_20 bool "4.20.x" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_20 -- 2.17.1

6 years, 4 months

FOSDEM

by Rouven Czerwinski

Hello, are any of the users or core developers which use OP-TEE coming to FOSDEM? Maybe we can organize a meetup. Regards, Rouven Czerwinski

6 years, 4 months

[PATCH v5 0/4] Introduce TEE bus driver framework

by Sumit Garg

This series introduces a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/ services. Patch #1 adds TEE bus concept where devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. This concept also allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Patch #2 adds supp_nowait flag for non-blocking requests arising via TEE internal client interface. Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/services for TEE bus. Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver. On ARM SoC's with TrustZone enabled, peripherals like entropy sources might not be accessible to normal world (linux in this case) and rather accessible to secure world (OP-TEE in this case) only. So this driver aims to provides a generic interface to OP-TEE based random number generator service. Example case is Developerbox based on Socionext's Synquacer SoC [1] which provides 7 thermal sensors accessible from secure world only which could be used as entropy sources (thermal/measurement noise). [1] https://www.96boards.org/product/developerbox/ Changes in v5: 1. Add support in module device table for TEE bus devices. 2. Correct license for optee-rng module. Changes in v4: 1. Use typedef instead of single member tee_client_device_id struct. 2. Incorporate TEE bus nitpicks. Changes in v3: 1. Fixed bus error path in Patch #1. 2. Reversed order of Patch #2 and #3. 3. Fixed miscellaneous syntax comments and memory leak. 4. Added comments in Patch #2 for supp_nowait flag. Changes in v2: Based on review comments, the scope of this series has increased as follows: 1. Added TEE bus driver framework. 2. Added OP-TEE based device enumeration. 3. Register optee-rng driver as TEE bus driver. 4. Removed DT dependency for optee-rng device UUID. 5. Added supp_nowait flag. Sumit Garg (4): tee: add bus driver framework for TEE based devices tee: add supp_nowait flag in tee_context struct tee: optee: add TEE bus device enumeration support hwrng: add OP-TEE based rng driver MAINTAINERS | 5 + drivers/char/hw_random/Kconfig | 15 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/optee-rng.c | 274 +++++++++++++++++++++++++++++++++++++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 4 + drivers/tee/optee/device.c | 153 +++++++++++++++++++++ drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/supp.c | 10 +- drivers/tee/tee_core.c | 70 +++++++++- include/linux/mod_devicetable.h | 9 ++ include/linux/tee_drv.h | 38 ++++- scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 19 +++ 14 files changed, 599 insertions(+), 6 deletions(-) create mode 100644 drivers/char/hw_random/optee-rng.c create mode 100644 drivers/tee/optee/device.c -- 2.7.4

6 years, 4 months

OP-TEE 3.4.0 has been released

by Jerome Forissier

Hi all, OP-TEE 3.4.0 is now ready. Thanks to all of you who have contributed to this new version. Links to commits and pull requests incorporated in this release are in the change log [1]. As usual, I have tagged the relevant OP-TEE/* and linaro-swg/* Gits [2] and I have created stable manifests in manifest.git (see branch 3.4.0, which is also tagged 3.4.0 [3]). So, it should be easy for anyone to retrieve and build this release. [1] https://github.com/OP-TEE/optee_os/blob/3.4.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/releases/tag/3.4.0 https://github.com/OP-TEE/optee_client/releases/tag/3.4.0 https://github.com/OP-TEE/optee_test/releases/tag/3.4.0 https://github.com/OP-TEE/build/releases/tag/3.4.0 https://github.com/linaro-swg/optee_examples/releases/tag/3.4.0 https://github.com/linaro-swg/optee_benchmark/releases/tag/3.4.0 [3] https://github.com/OP-TEE/manifest/releases/tag/3.4.0 Thanks, -- Jerome

6 years, 4 months

[PATCH 1/1] tee: add cancellation support to client interface

by Igor Opaniuk

Add support of cancellation request to the TEE kernel internal client interface. Can be used by software TPM drivers, that leverage TEE under the hood (for instance in TPM2.0 mobile profile), for requesting cancellation of time-consuming operations (RSA key-pair generation etc.). Signed-off-by: Igor Opaniuk <igor.opaniuk(a)linaro.org> --- drivers/tee/tee_core.c | 12 ++++++++++++ include/linux/tee_drv.h | 14 ++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 7b2bb4c..aba71a8 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1027,6 +1027,18 @@ int tee_client_invoke_func(struct tee_context *ctx, } EXPORT_SYMBOL_GPL(tee_client_invoke_func); +int tee_client_cancel_req(struct tee_context *ctx, + u32 cancel_id, + u32 session) +{ + + if (!ctx->teedev->desc->ops->cancel_req) + return -EINVAL; + return ctx->teedev->desc->ops->cancel_req(ctx, cancel_id, + session); +} +EXPORT_SYMBOL_GPL(tee_client_cancel_req); + static int __init tee_init(void) { int rc; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 6cfe058..62a0b56 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -526,6 +526,20 @@ int tee_client_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param); +/** + * tee_client_cancel_req() - Request cancellation of the previous open-session + * or invoke-command operations in a Trusted Application + * @ctx: TEE Context + * @arg: Unique cancel request id + * @param: Session id + * + * Returns < 0 on error else see @arg->ret for result. + */ +int tee_client_cancel_req(struct tee_context *ctx, + u32 cancel_id, + u32 session); + + static inline bool tee_param_is_memref(struct tee_param *param) { switch (param->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK) { -- 2.7.4

6 years, 4 months

[PATCH v4 0/4] Introduce TEE bus driver framework

by Sumit Garg

This series introduces a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/ services. Patch #1 adds TEE bus concept where devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. This concept also allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Patch #2 adds supp_nowait flag for non-blocking requests arising via TEE internal client interface. Patch #3 adds TEE bus device enumeration support for OP-TEE. OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/services for TEE bus. Patch #4 adds OP-TEE based hwrng driver which act as TEE bus driver. On ARM SoC's with TrustZone enabled, peripherals like entropy sources might not be accessible to normal world (linux in this case) and rather accessible to secure world (OP-TEE in this case) only. So this driver aims to provides a generic interface to OP-TEE based random number generator service. Example case is Developerbox based on Socionext's Synquacer SoC [1] which provides 7 thermal sensors accessible from secure world only which could be used as entropy sources (thermal/measurement noise). [1] https://www.96boards.org/product/developerbox/ Changes in v4: 1. Use typedef instead of single member tee_client_device_id struct. 2. Incorporate TEE bus nitpicks. Changes in v3: 1. Fixed bus error path in Patch #1. 2. Reversed order of Patch #2 and #3. 3. Fixed miscellaneous syntax comments and memory leak. 4. Added comments in Patch #2 for supp_nowait flag. Changes in v2: Based on review comments, the scope of this series has increased as follows: 1. Added TEE bus driver framework. 2. Added OP-TEE based device enumeration. 3. Register optee-rng driver as TEE bus driver. 4. Removed DT dependency for optee-rng device UUID. 5. Added supp_nowait flag. Sumit Garg (4): tee: add bus driver framework for TEE based devices tee: add supp_nowait flag in tee_context struct tee: optee: add TEE bus device enumeration support hwrng: add OP-TEE based rng driver MAINTAINERS | 5 + drivers/char/hw_random/Kconfig | 15 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/optee-rng.c | 272 +++++++++++++++++++++++++++++++++++++ drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 4 + drivers/tee/optee/device.c | 153 +++++++++++++++++++++ drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/supp.c | 10 +- drivers/tee/tee_core.c | 58 +++++++- include/linux/tee_drv.h | 43 +++++- 11 files changed, 559 insertions(+), 6 deletions(-) create mode 100644 drivers/char/hw_random/optee-rng.c create mode 100644 drivers/tee/optee/device.c -- 2.7.4

6 years, 4 months

OP-TEE 3.4.0-rc1

by Jerome Forissier

[Sent to all e-mail addresses found in optee_os/MAINTAINERS] Dear OP-TEE users and contributors, FYI, the next OP-TEE release (3.4.0) is scheduled for January 25th. As usual, I will create the -rc1 tag one week before. In the meantime, please update your pending pull requests, help review patches on GitHub, run some tests on master etc. I will let you know when the -rc1 tag is ready for testing, at which point I will collect Tested-bys in a pull request and merge only bug fixes into master. Thanks for your continued help and support! Regards, -- Jerome

6 years, 5 months

← Newer
1
...
14
15
16
17
18
19
20
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev