- OP-TEE - lists.trustedfirmware.org

Linaro OP-TEE Contribution (LOC) monthly meeting October

by Jens Wiklander

Hi, OP-TEE Contributions (LOC) monthly meeting is planned for Tuesday, Oct 25 at 10.00 (UTC). Note, new time! If you have any topics you'd like to discuss, please let us know and we can schedule them. Meeting details: Date/time: October 25 at 10.00 (UTC) Meeting notes: http://bit.ly/loc-notes Project page: https://www.linaro.org/projects/#LOC Connection details =============== Join Zoom: https://linaro-org.zoom.us/j/93697277554?pwd=MGdFRU4xZjdDS2VSMzVMbGZIdnkwZz… Thanks, Jens on behalf of the Linaro OP-TEE team

4 years

2
2
0 0

OP-TEE 3.19 SPMC status

by Balint Dobszay

Hi All, This is a follow-up email to the OP-TEE 3.19 release, highlighting the updates to the SPMC and related components. Short summary of introduced changes: - Added support for running SPs loaded from the FIP (by TF-A). This is an alternative to the current embedded SP loading mechanism [1]. - Added a new suite to xtest (ffa_spmc) to enable testing the SPMC as part of the normal OP-TEE test procedure [2]. For more details on how to get, build and test the SPMC, please see [3]. Our 3.19 release related test results are captured on this page [4]. Regards, Balint [1] https://optee.readthedocs.io/en/latest/architecture/spmc.html#sp-loading-me… [2] https://github.com/OP-TEE/optee_test/blob/3.19.0/host/xtest/ffa_spmc_1000.c [3] https://developer.trustedfirmware.org/w/trusted-services/op-tee-spmc [4] https://developer.trustedfirmware.org/w/trusted-services/op-tee-spmc/releas…

4 years

1
0
0 0

OP-TEE 3.19.0 has been released

by Jérôme Forissier

Hi, I'm pleased to announce that OP-TEE version 3.19.0 is now available. As usual, the list of changes can be found in the changelog [1]. A blog post will be published soon on trustedfirmware.org [3]. A big thank you to everyone who participated with contributions and helping out with testing the release [2]. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/afacf356f9593a7f83cae9f96026824ec… [3] https://www.trustedfirmware.org/blog/ Regards, -- Jerome

4 years

1
0
0 0

[PATCH] optee: Add __init/__exit annotations to module init/exit funcs

by Xiu Jianfeng

Add missing __init/__exit annotations to module init/exit funcs. Signed-off-by: Xiu Jianfeng <xiujianfeng(a)huawei.com> --- drivers/tee/optee/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index daf07737c4fd..2a258bd3b6b5 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -188,7 +188,7 @@ void optee_remove_common(struct optee *optee) static int smc_abi_rc; static int ffa_abi_rc; -static int optee_core_init(void) +static int __init optee_core_init(void) { /* * The kernel may have crashed at the same time that all available @@ -210,7 +210,7 @@ static int optee_core_init(void) } module_init(optee_core_init); -static void optee_core_exit(void) +static void __exit optee_core_exit(void) { if (!smc_abi_rc) optee_smc_abi_unregister(); -- 2.17.1

4 years, 1 month

3
2
0 0

Preparing for OP-TEE 3.19.0

by Jérôme Forissier

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.19.0 is scheduled to be released on 2022-10-14. So, now is a good time to start testing the master branch on the various platforms and report/fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/5550 As usual, we will create a release candidate tag one week before the release date for final testing. In addition to that you can find some additional information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, -- Jerome

4 years, 1 month

1
1
0 0

Linaro OP-TEE Contributions (LOC) monthly meeting

by Jens Wiklander

Hi, We don't have any topics for the meeting today, so let's cancel it. The time slot we've allocated for this meeting is either bad or worse for me so I'd like to try and find a new time slot. Please use the doodle link [1] below to record your preferences. The doodle poll is public so feel free to email me directly instead in case you're more comfortable with that. This is my first time creating a doodle poll, so apologies if I've made a mess of it. As noted in the poll we're looking for a day and time in the fourth week of the month. We're using the CET time zone as many of us are in the time zone. If you can't find any time that works for you please send me a mail with more suitable times and I'll try to work out something. Let's give this a week or so to possibly settle on a new time slot. [1] https://doodle.com/meeting/participate/id/dJqR4Eyb Thanks, Jens

4 years, 1 month

1
2
0 0

[PATCH 0/4] Remove get_kernel_pages()

by ira.weiny＠intel.com

From: Ira Weiny <ira.weiny(a)intel.com> get_kernel_pages() only had one caller [shm_get_kernel_pages()] which did not need the functionality it provided. Furthermore, it called kmap_to_page() which we are looking to removed. Alter shm_get_kernel_pages() to no longer call get_kernel_pages() and remove get_kernel_pages(). Along the way it was noted that shm_get_kernel_pages() does not have any need to support vmalloc'ed addresses either. Remove that functionality to clean up the logic. This series also fixes and uses is_kmap_addr(). Ira Weiny (4): highmem: Enhance is_kmap_addr() to check kmap_local_page() mappings tee: Remove vmalloc page support tee: Remove call to get_kernel_pages() mm: Remove get_kernel_pages() drivers/tee/tee_shm.c | 41 ++++++++++++-------------------- include/linux/highmem-internal.h | 5 +++- include/linux/mm.h | 2 -- mm/swap.c | 30 ----------------------- 4 files changed, 19 insertions(+), 59 deletions(-) base-commit: 274d7803837da78dfc911bcda0d593412676fc20 -- 2.37.2

4 years, 1 month

7
14
0 0

[PATCH v3 00/10] firmware: arm_ffa: Refactoring and initial/minor v1.1 update

by Sudeep Holla

Hi All, This series is just some refactoring in preparation to add FF-A v1.1 support. It doesn't have any memory layout or notification changes supported in v1.1 yet. Regards, Sudeep v2[2]->v3: - Fixed the logic to set 32bit mode which was wrong. - Ensured that we advance each partition info size by returned size even if the size is greater than the partition_info structure, we will still just copy the right size. v1[1]->v2[2]: - Merged dropping of ffa_ops in optee_ffa structure and using ffa_dev->ops into single patch - Added separate patch(didn't fit any patch strictly to fit in) to rename ffa_dev_ops as ffa_ops as suggested by Sumit - Fixed some minor comments, handling size > structure size in partition_info_get and added extra parameter to ffa_features to get both possible output/interface properties. [1] https://lore.kernel.org/all/20220830100700.344594-1-sudeep.holla@arm.com [2] https://lore.kernel.org/all/20220902124032.788488-1-sudeep.holla@arm.com Sudeep Holla (10): firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_dev tee: optee: Drop ffa_ops in optee_ffa structure using ffa_dev->ops directly firmware: arm_ffa: Remove ffa_dev_ops_get() firmware: arm_ffa: Add support for querying FF-A features firmware: arm_ffa: Use FFA_FEATURES to detect if native versions are supported firmware: arm_ffa: Make memory apis ffa_device independent firmware: arm_ffa: Rename ffa_dev_ops as ffa_ops firmware: arm_ffa: Add v1.1 get_partition_info support firmware: arm_ffa: Set up 32bit execution mode flag using partiion property firmware: arm_ffa: Split up ffa_ops into info, message and memory operations drivers/firmware/arm_ffa/bus.c | 4 +- drivers/firmware/arm_ffa/driver.c | 131 +++++++++++++++++++++++------- drivers/tee/optee/ffa_abi.c | 46 +++++------ drivers/tee/optee/optee_private.h | 1 - include/linux/arm_ffa.h | 36 +++++--- 5 files changed, 151 insertions(+), 67 deletions(-) -- 2.37.3

4 years, 2 months

2
14
0 0

[PATCH v2 00/10] firmware: arm_ffa: Refactoring and initial/minor v1.1 update

by Sudeep Holla

Hi All, This series is just some refactoring in preparation to add FF-A v1.1 support. It doesn't have any memory layout or notification changes supported in v1.1 yet. Regards, Sudeep v1[1]->v2: - Merged dropping of ffa_ops in optee_ffa structure and using ffa_dev->ops into single patch - Added separate patch(didn't fit any patch strictly to fit in) to rename ffa_dev_ops as ffa_ops as suggested by Sumit - Fixed some minor comments, handling size > structure size in partition_info_get and added extra parameter to ffa_features to get both possible output/interface properties. [1] https://lore.kernel.org/all/20220830100700.344594-1-sudeep.holla@arm.com/ Sudeep Holla (10): firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_dev tee: optee: Drop ffa_ops in optee_ffa structure using ffa_dev->ops directly firmware: arm_ffa: Remove ffa_dev_ops_get() firmware: arm_ffa: Add support for querying FF-A features firmware: arm_ffa: Use FFA_FEATURES to detect if native versions are supported firmware: arm_ffa: Make memory apis ffa_device independent firmware: arm_ffa: Rename ffa_dev_ops as ffa_ops firmware: arm_ffa: Add v1.1 get_partition_info support firmware: arm_ffa: Set up 32bit execution mode flag using partiion property firmware: arm_ffa: Split up ffa_ops into info, message and memory operations drivers/firmware/arm_ffa/bus.c | 4 +- drivers/firmware/arm_ffa/driver.c | 130 +++++++++++++++++++++++------- drivers/tee/optee/ffa_abi.c | 46 +++++------ drivers/tee/optee/optee_private.h | 1 - include/linux/arm_ffa.h | 36 ++++++--- 5 files changed, 150 insertions(+), 67 deletions(-) -- 2.37.3

4 years, 2 months

3
19
0 0

Re: [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application

by Sumit Garg

+ TEE ML On Fri, 2 Sept 2022 at 18:48, Maximilian Luz <luzmaximilian(a)gmail.com> wrote: > > Hi, > > On 9/2/22 09:26, Sumit Garg wrote: > > Hi Maximilian, > > > > On 02/08/22 18:52, Maximilian Luz wrote: > > [...] > > >> Thanks for this information! So as far as I understand it, this is currently an > >> interface to user-space only, i.e. does not allow in-kernel drivers for apps? > > > > The Linux TEE framework already provides an in-kernel interface to TEE as well via TEE bus [1]. There are already multiple kernel drivers [2] [3] [4] [5] [6] [7] using it. So an EFI driver can be an addition to that. > > > > Now coming on to TEE implementations, the drivers I mentioned are based on OP-TEE where devices are queried/enumerated during OP-TEE probe here [8]. So in similar manner QTEE smcinvoke driver should be able to register devices on the TEE bus. > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… > > > > [2] drivers/char/tpm/tpm_ftpm_tee.c > > > > [3] drivers/char/hw_random/optee-rng.c > > > > [4] drivers/firmware/arm_scmi/optee.c > > > > [5] security/keys/trusted-keys/trusted_tee.c > > > > [6] drivers/firmware/broadcom/tee_bnxt_fw.c > > > > [7] drivers/rtc/rtc-optee.c > > > > [8] drivers/tee/optee/device.c > > Thanks for those links! > > I think it would indeed be good if we could make it work via that > interface and I guess that should generally be possible. As far as I can > see, the biggest problem might be that the current firmware doesn't seem > to use UUIDs, so I guess we might need to emulate them somehow. > Okay, so I had a brief look at your driver to get an idea how QTEE identifies its trusted/secure applications. AFAIU, it uses constant strings as follows: #define QCTEE_UEFISEC_APP_NAME "qcom.tz.uefisecapp" I think we should be able to extend the TEE bus concept to accept constant strings as device IDs as well. So if a driver wants to support both OP-TEE and QTEE based apps then it can put corresponding identifiers (UUID or a constant string) in the TEE device match ID table. This way we should be able to support other TEE implementations as I think any other identifier apart from UUID can be represented as a constant string. If anyone else has any better then feel free to discuss. -Sumit > It would be great if someone with some actual knowledge of the firmware > used on those devices could have a look at this and provide some > insights. > > My plan for now is to hold off on the UEFI variable driver until we have > a (proper) TEE driver, which unfortunately might be a bit out of my > depth. I'm happy to help out in any way I can though. > > Regards, > Max

4 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE