- OP-TEE - lists.trustedfirmware.org

Re: [PATCH 2/4] tee: Remove vmalloc page support

by Sumit Garg

Hi Phil, Please don't top-post in the OSS mailing list. On Wed, 5 Oct 2022 at 08:59, Phil Chang (張世勳) <Phil.Chang(a)mediatek.com> wrote: > > Hi Sumit > > Thanks for mentioning that, in fact, our product is low memory devices, and continuous pages are extremely valuable. > Although our driver is not upstream yet but highly dependent on tee shm vmalloc support, Sorry but you need to get your driver mainline in order to support vmalloc interface. As otherwise it's a maintenance nightmare to support interfaces in the mainline for out-of-tree drivers. -Sumit > some scenarios are driver alloc high order pages but system memory is fragmentation so that alloc failed. > In this situation, vmalloc support is important and gives flexible usage to user. > > > -----Original Message----- > From: Sumit Garg <sumit.garg(a)linaro.org> > Sent: Monday, October 3, 2022 2:57 PM > To: ira.weiny(a)intel.com > Cc: Jens Wiklander <jens.wiklander(a)linaro.org>; Andrew Morton <akpm(a)linux-foundation.org>; Al Viro <viro(a)zeniv.linux.org.uk>; Fabio M. De Francesco <fmdefrancesco(a)gmail.com>; Christoph Hellwig <hch(a)lst.de>; Linus Torvalds <torvalds(a)linux-foundation.org>; op-tee(a)lists.trustedfirmware.org; linux-kernel(a)vger.kernel.org; linux-mm(a)kvack.org; Phil Chang (張世勳) <Phil.Chang(a)mediatek.com> > Subject: Re: [PATCH 2/4] tee: Remove vmalloc page support > > + Phil > > Hi Ira, > > On Sun, 2 Oct 2022 at 05:53, <ira.weiny(a)intel.com> wrote: > > > > From: Ira Weiny <ira.weiny(a)intel.com> > > > > The kernel pages used by shm_get_kernel_pages() are allocated using > > GFP_KERNEL through the following call stack: > > > > trusted_instantiate() > > trusted_payload_alloc() -> GFP_KERNEL > > <trusted key op> > > tee_shm_register_kernel_buf() > > register_shm_helper() > > shm_get_kernel_pages() > > > > Where <trusted key op> is one of: > > > > trusted_key_unseal() > > trusted_key_get_random() > > trusted_key_seal() > > > > Remove the vmalloc page support from shm_get_kernel_pages(). Replace > > with a warn on once. > > > > Cc: Jens Wiklander <jens.wiklander(a)linaro.org> > > Cc: Al Viro <viro(a)zeniv.linux.org.uk> > > Cc: "Fabio M. De Francesco" <fmdefrancesco(a)gmail.com> > > Cc: Christoph Hellwig <hch(a)lst.de> > > Cc: Linus Torvalds <torvalds(a)linux-foundation.org> > > Signed-off-by: Ira Weiny <ira.weiny(a)intel.com> > > > > --- > > Jens I went with the suggestion from Linus and Christoph and rejected > > vmalloc addresses. I did not hear back from you regarding Linus' > > question if the vmalloc page support was required by an up coming > > patch set or not. So I assumed it was something out of tree. > > It looks like I wasn't CC'd to that conversation. IIRC, support for vmalloc addresses was added recently by Phil here [1]. So I would like to give him a chance if he is planning to post a corresponding kernel driver upstream. > > [1] https://urldefense.com/v3/__https://lists.trustedfirmware.org/archives/list… > > -Sumit > > > --- > > drivers/tee/tee_shm.c | 36 ++++++++++++------------------------ > > 1 file changed, 12 insertions(+), 24 deletions(-) > > > > diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index > > 27295bda3e0b..527a6eabc03e 100644 > > --- a/drivers/tee/tee_shm.c > > +++ b/drivers/tee/tee_shm.c > > @@ -24,37 +24,25 @@ static void shm_put_kernel_pages(struct page > > **pages, size_t page_count) static int shm_get_kernel_pages(unsigned long start, size_t page_count, > > struct page **pages) { > > + struct kvec *kiov; > > size_t n; > > int rc; > > > > - if (is_vmalloc_addr((void *)start)) { > > - struct page *page; > > - > > - for (n = 0; n < page_count; n++) { > > - page = vmalloc_to_page((void *)(start + PAGE_SIZE * n)); > > - if (!page) > > - return -ENOMEM; > > - > > - get_page(page); > > - pages[n] = page; > > - } > > - rc = page_count; > > - } else { > > - struct kvec *kiov; > > - > > - kiov = kcalloc(page_count, sizeof(*kiov), GFP_KERNEL); > > - if (!kiov) > > - return -ENOMEM; > > + if (WARN_ON_ONCE(is_vmalloc_addr((void *)start))) > > + return -EINVAL; > > > > - for (n = 0; n < page_count; n++) { > > - kiov[n].iov_base = (void *)(start + n * PAGE_SIZE); > > - kiov[n].iov_len = PAGE_SIZE; > > - } > > + kiov = kcalloc(page_count, sizeof(*kiov), GFP_KERNEL); > > + if (!kiov) > > + return -ENOMEM; > > > > - rc = get_kernel_pages(kiov, page_count, 0, pages); > > - kfree(kiov); > > + for (n = 0; n < page_count; n++) { > > + kiov[n].iov_base = (void *)(start + n * PAGE_SIZE); > > + kiov[n].iov_len = PAGE_SIZE; > > } > > > > + rc = get_kernel_pages(kiov, page_count, 0, pages); > > + kfree(kiov); > > + > > return rc; > > } > > > > -- > > 2.37.2 > >

3 years, 5 months

6
10
0 0

register_ddr() with larger than physical RAM size

by Jeffrey Kardatzke

Hello, New to this list, I'm working on integrating Op-Tee into ChromeOS ARM devices for the purpose of Widevine DRM. Does anybody know if Op-Tee creates mappings in the MMU that go beyond the registered TZ memory region and the static non-secure shared memory region? TL;DR Does anyone know if there would be problems associated with invoking register_ddr()[1] with a size larger than the physical RAM size? The reason I want to do this is because we have multiple different SKUs for the same reference board, and for ChromeOS we build per-board images and not per-SKU images. We could use a DT to do this, but that's running into other issues...so I'm trying to determine if this easy fix will solve the problem w/out creating new ones. (it does work fine when I test it) I understand that an exploited normal world could send a PA pointing to a region outside of the physical bounds for dynamic shared memory, and then Op-Tee would try to map that and undesirable things may happen (but I don't think they would lead to secure world exploits since the memory will be mapped as non-secure, so it shouldn't be any worse that the normal world trying to access physical memory out of bounds). One of the main concerns is around whether Op-Tee is creating mappings in the MMU that reference the whole nonsecure DDR size for some other reason. Then the CPU may do speculative execution and try to access the physical memory at that invalid mapping and create problems, which could then lead to failure when someone isn't trying to exploit the system. Does anybody know if Op-Tee creates mappings in the MMU that go beyond the registered TZ memory region and the static non-secure shared memory region? [1] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-mediatek/… Thanks, -- Jeffrey Kardatzke jkardatzke(a)google.com Google, Inc.

3 years, 6 months

2
2
0 0

[GIT PULL] Add __init/__exit annotations OP-TEE driver for v6.2

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch which adds __init/__exit annotations to the OP-TEE driver module. Thanks, Jens The following changes since commit 4fe89d07dcc2804c8b562f6c7896a45643d34b2f: Linux 6.0 (2022-10-02 14:09:07 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-for-6.2 for you to fetch changes up to bd52407221b4702af690456b2b6006fa6440e893: optee: Add __init/__exit annotations to module init/exit funcs (2022-10-11 11:20:16 +0200) ---------------------------------------------------------------- Add missing __init/__exit annotations to OP-TEE driver ---------------------------------------------------------------- Xiu Jianfeng (1): optee: Add __init/__exit annotations to module init/exit funcs drivers/tee/optee/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

3 years, 6 months

1
0
0 0

[PATCH] tee: optee: fix possible memory leak in optee_register_device()

by Yang Yingliang

If device_register() returns error in optee_register_device(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and optee_device is freed in optee_release_device(). Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/tee/optee/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c index f3947be13e2e..64f0e047c23d 100644 --- a/drivers/tee/optee/device.c +++ b/drivers/tee/optee/device.c @@ -80,7 +80,7 @@ static int optee_register_device(const uuid_t *device_uuid) rc = device_register(&optee_device->dev); if (rc) { pr_err("device registration failed, err: %d\n", rc); - kfree(optee_device); + put_device(&optee_device->dev); } return rc; -- 2.25.1

3 years, 6 months

3
2
0 0

[GIT PULL] Fix possible memory leak OP-TEE driver for v6.1

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch in the OP-TEE driver which fixes a possible memory leak in the error path of optee_register_device(). Thanks, Jens The following changes since commit 094226ad94f471a9f19e8f8e7140a09c2625abaa: Linux 6.1-rc5 (2022-11-13 13:12:55 -0800) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-fix-for-6.1 for you to fetch changes up to cce616e012c215d65c15e5d1afa73182dea49389: tee: optee: fix possible memory leak in optee_register_device() (2022-11-17 09:22:12 +0100) ---------------------------------------------------------------- Fix possible memory leak in optee_register_device() ---------------------------------------------------------------- Yang Yingliang (1): tee: optee: fix possible memory leak in optee_register_device() drivers/tee/optee/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

3 years, 6 months

1
0
0 0

[PATCH] tee: optee: fix possible memory leak in optee_register_device()

by ruanjinjie

If device_register() returns error in optee_register_device(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked. Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized. Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support") Signed-off-by: ruanjinjie <ruanjinjie(a)huawei.com> --- drivers/tee/optee/device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c index f3947be13e2e..64f0e047c23d 100644 --- a/drivers/tee/optee/device.c +++ b/drivers/tee/optee/device.c @@ -80,7 +80,7 @@ static int optee_register_device(const uuid_t *device_uuid) rc = device_register(&optee_device->dev); if (rc) { pr_err("device registration failed, err: %d\n", rc); - kfree(optee_device); + put_device(&optee_device->dev); } return rc; -- 2.25.1

3 years, 6 months

2
1
0 0

Linaro OP-TEE Contribution (LOC) monthly meeting November 22

by Jens Wiklander

Hi, For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I have one topic for the LOC: Can we deprecate paging of OP-TEE on Armv8-A platforms using FF-A? Any other topic? Thanks, Jens

3 years, 6 months

1
0
0 0

[PATCH] tee: optee: Populate child nodes in probe function

by Ludvig Pärsson

Currently there is no dependency between the "linaro,scmi-optee" driver and the tee_core. If the scmi-optee driver gets probed before the tee_bus_type is initialized, then we will get an unwanted error print. This patch enables putting scmi-optee nodes as children to the optee node in devicetree, which indirectly creates the missing dependency. Signed-off-by: Ludvig Pärsson <ludvig.parsson(a)axis.com> --- drivers/tee/optee/smc_abi.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index a1c1fa1a9c28..be6f02fd5a7f 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1533,6 +1533,11 @@ static int optee_probe(struct platform_device *pdev) if (rc) goto err_disable_shm_cache; + /* Populate any dependent child node (if any) */ + rc = devm_of_platform_populate(&pdev->dev); + if (rc) + goto err_disable_shm_cache; + pr_info("initialized driver\n"); return 0; -- 2.30.2

3 years, 6 months

4
6
0 0

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

3 years, 6 months

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…

3 years, 7 months

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

3 years, 7 months

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

3 years, 7 months

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

3 years, 7 months

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

3 years, 7 months

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

3 years, 7 months

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

3 years, 8 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

3 years, 8 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

3 years, 8 months

1
0
0 0

[PATCH 0/9] 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 Sudeep Holla (9): firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_dev tee: optee: Use 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: Add v1.1 get_partition_info support tee: optee: Drop ffa_ops in optee_ffa structure firmware: arm_ffa: Split up ffa_dev_ops into info, message and memory operations drivers/firmware/arm_ffa/bus.c | 4 +- drivers/firmware/arm_ffa/driver.c | 111 ++++++++++++++++++++++-------- drivers/tee/optee/ffa_abi.c | 40 +++++------ drivers/tee/optee/optee_private.h | 1 - include/linux/arm_ffa.h | 34 +++++---- 5 files changed, 127 insertions(+), 63 deletions(-) -- 2.37.2

3 years, 8 months

3
27
0 0

LOC meetings today

by Jérôme Forissier

Hi, The LOC meeting will start shortly. Sorry for the late notice. https://bit.ly/loc-notes -- Jerome

3 years, 8 months

1
0
0 0

[GIT PULL] Fix TEE system compiler warning fo4r v6.0

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch which fixes a recently introduced compiler warning the TEE subsystem. Thanks, Jens The following changes since commit 1c23f9e627a7b412978b4e852793c5e3c3efc555: Linux 6.0-rc2 (2022-08-21 17:32:54 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/tee-fix-for-v6.0 for you to fetch changes up to eccd7439709810127563e7e3e49b8b44c7b2791d: tee: fix compiler warning in tee_shm_register() (2022-08-25 11:40:06 +0200) ---------------------------------------------------------------- Add a missing include in the TEE subsystem ---------------------------------------------------------------- Jens Wiklander (1): tee: fix compiler warning in tee_shm_register() drivers/tee/tee_shm.c | 1 + 1 file changed, 1 insertion(+)

3 years, 8 months

1
0
0 0

[PATCH] tee: fix compiler warning in tee_shm_register()

by Jens Wiklander

Include <linux/uaccess.h> to avoid the warning: drivers/tee/tee_shm.c: In function 'tee_shm_register': >> drivers/tee/tee_shm.c:242:14: error: implicit declaration of function 'access_ok' [-Werror=implicit-function-declaration] 242 | if (!access_ok((void __user *)addr, length)) | ^~~~~~~~~ cc1: some warnings being treated as errors Fixes: 573ae4f13f63 ("tee: add overflow check in register_shm_helper()") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/tee_shm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 1175f3a46859..27295bda3e0b 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -9,6 +9,7 @@ #include <linux/sched.h> #include <linux/slab.h> #include <linux/tee_drv.h> +#include <linux/uaccess.h> #include <linux/uio.h> #include "tee_private.h" -- 2.31.1

3 years, 8 months

2
2
0 0

[PATCH v3] tee: add overflow check in register_shm_helper()

by Jens Wiklander

With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference. [ 14.141620] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 [ 14.142556] Mem abort info: [ 14.142829] ESR = 0x0000000096000044 [ 14.143237] EC = 0x25: DABT (current EL), IL = 32 bits [ 14.143742] SET = 0, FnV = 0 [ 14.144052] EA = 0, S1PTW = 0 [ 14.144348] FSC = 0x04: level 0 translation fault [ 14.144767] Data abort info: [ 14.145053] ISV = 0, ISS = 0x00000044 [ 14.145394] CM = 0, WnR = 1 [ 14.145766] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004278e000 [ 14.146279] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 [ 14.147435] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 14.148026] Modules linked in: [ 14.148595] CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 [ 14.149204] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ 14.149832] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 14.150481] pc : internal_get_user_pages_fast+0x474/0xa80 [ 14.151640] lr : internal_get_user_pages_fast+0x404/0xa80 [ 14.152408] sp : ffff80000a88bb30 [ 14.152711] x29: ffff80000a88bb30 x28: 0000fffff836d000 x27: 0000fffff836e000 [ 14.153580] x26: fffffc0000000000 x25: fffffc0000f4a1c0 x24: ffff00000289fb70 [ 14.154634] x23: ffff000002702e08 x22: 0000000000040001 x21: ffff8000097eec60 [ 14.155378] x20: 0000000000f4a1c0 x19: 00e800007d287f43 x18: 0000000000000000 [ 14.156215] x17: 0000000000000000 x16: 0000000000000000 x15: 0000fffff836cfb0 [ 14.157068] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 14.157747] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 14.158576] x8 : ffff00000276ec80 x7 : 0000000000000000 x6 : 000000000000003f [ 14.159243] x5 : 0000000000000000 x4 : ffff000041ec4eac x3 : ffff000002774cb8 [ 14.159977] x2 : 0000000000000004 x1 : 0000000000000010 x0 : 0000000000000000 [ 14.160883] Call trace: [ 14.161166] internal_get_user_pages_fast+0x474/0xa80 [ 14.161763] pin_user_pages_fast+0x24/0x4c [ 14.162227] register_shm_helper+0x194/0x330 [ 14.162734] tee_shm_register_user_buf+0x78/0x120 [ 14.163290] tee_ioctl+0xd0/0x11a0 [ 14.163739] __arm64_sys_ioctl+0xa8/0xec [ 14.164227] invoke_syscall+0x48/0x114 [ 14.164653] el0_svc_common.constprop.0+0x44/0xec [ 14.165130] do_el0_svc+0x2c/0xc0 [ 14.165498] el0_svc+0x2c/0x84 [ 14.165847] el0t_64_sync_handler+0x1ac/0x1b0 [ 14.166258] el0t_64_sync+0x18c/0x190 [ 14.166878] Code: 91002318 11000401 b900f7e1 f9403be1 (f820d839) [ 14.167666] ---[ end trace 0000000000000000 ]--- Fix this by adding an overflow check when calculating the end of the memory range. Also add an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early. Fixes: 033ddf12bcf5 ("tee: add register user memory") Cc: stable(a)vger.kernel.org Reported-by: Nimish Mishra <neelam.nimish(a)gmail.com> Reported-by: Anirban Chakraborty <ch.anirban00727(a)gmail.com> Reported-by: Debdeep Mukhopadhyay <debdeep.mukhopadhyay(a)gmail.com> Suggested-by: Linus Torvalds <torvalds(a)linuxfoundation.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- v2 -> v3: - Public review - Relies entirely on access_ok() for overflow checks as suggested - Check against zero registersted pages is kept - Replaced Suggested-by tag v1 -> v2: - Non-public review - Added access_ok() and overflow check with roundup() drivers/tee/tee_shm.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index f2b1bcefcadd..a88669d6ea68 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -240,6 +240,14 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, void *ret; int rc; + addr = untagged_addr(addr); + start = rounddown(addr, PAGE_SIZE); + num_pages = (roundup(addr + length, PAGE_SIZE) - start) / PAGE_SIZE; + + /* Error out early if no pages are to be registered */ + if (!num_pages) + return ERR_PTR(-EINVAL); + if (!tee_device_get(teedev)) return ERR_PTR(-EINVAL); @@ -261,11 +269,8 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, shm->flags = flags; shm->ctx = ctx; shm->id = id; - addr = untagged_addr(addr); - start = rounddown(addr, PAGE_SIZE); shm->offset = addr - start; shm->size = length; - num_pages = (roundup(addr + length, PAGE_SIZE) - start) / PAGE_SIZE; shm->pages = kcalloc(num_pages, sizeof(*shm->pages), GFP_KERNEL); if (!shm->pages) { ret = ERR_PTR(-ENOMEM); @@ -326,6 +331,9 @@ struct tee_shm *tee_shm_register_user_buf(struct tee_context *ctx, void *ret; int id; + if (!access_ok((void __user *)addr, length)) + return ERR_PTR(-EFAULT); + mutex_lock(&teedev->mutex); id = idr_alloc(&teedev->idr, NULL, 1, 0, GFP_KERNEL); mutex_unlock(&teedev->mutex); -- 2.31.1

3 years, 9 months

3
3
0 0

[PATCH v2] tee: add overflow check in register_shm_helper()

by Jens Wiklander

With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference. [ 14.141620] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 [ 14.142556] Mem abort info: [ 14.142829] ESR = 0x0000000096000044 [ 14.143237] EC = 0x25: DABT (current EL), IL = 32 bits [ 14.143742] SET = 0, FnV = 0 [ 14.144052] EA = 0, S1PTW = 0 [ 14.144348] FSC = 0x04: level 0 translation fault [ 14.144767] Data abort info: [ 14.145053] ISV = 0, ISS = 0x00000044 [ 14.145394] CM = 0, WnR = 1 [ 14.145766] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004278e000 [ 14.146279] [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 [ 14.147435] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 14.148026] Modules linked in: [ 14.148595] CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 [ 14.149204] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ 14.149832] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 14.150481] pc : internal_get_user_pages_fast+0x474/0xa80 [ 14.151640] lr : internal_get_user_pages_fast+0x404/0xa80 [ 14.152408] sp : ffff80000a88bb30 [ 14.152711] x29: ffff80000a88bb30 x28: 0000fffff836d000 x27: 0000fffff836e000 [ 14.153580] x26: fffffc0000000000 x25: fffffc0000f4a1c0 x24: ffff00000289fb70 [ 14.154634] x23: ffff000002702e08 x22: 0000000000040001 x21: ffff8000097eec60 [ 14.155378] x20: 0000000000f4a1c0 x19: 00e800007d287f43 x18: 0000000000000000 [ 14.156215] x17: 0000000000000000 x16: 0000000000000000 x15: 0000fffff836cfb0 [ 14.157068] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 14.157747] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 14.158576] x8 : ffff00000276ec80 x7 : 0000000000000000 x6 : 000000000000003f [ 14.159243] x5 : 0000000000000000 x4 : ffff000041ec4eac x3 : ffff000002774cb8 [ 14.159977] x2 : 0000000000000004 x1 : 0000000000000010 x0 : 0000000000000000 [ 14.160883] Call trace: [ 14.161166] internal_get_user_pages_fast+0x474/0xa80 [ 14.161763] pin_user_pages_fast+0x24/0x4c [ 14.162227] register_shm_helper+0x194/0x330 [ 14.162734] tee_shm_register_user_buf+0x78/0x120 [ 14.163290] tee_ioctl+0xd0/0x11a0 [ 14.163739] __arm64_sys_ioctl+0xa8/0xec [ 14.164227] invoke_syscall+0x48/0x114 [ 14.164653] el0_svc_common.constprop.0+0x44/0xec [ 14.165130] do_el0_svc+0x2c/0xc0 [ 14.165498] el0_svc+0x2c/0x84 [ 14.165847] el0t_64_sync_handler+0x1ac/0x1b0 [ 14.166258] el0t_64_sync+0x18c/0x190 [ 14.166878] Code: 91002318 11000401 b900f7e1 f9403be1 (f820d839) [ 14.167666] ---[ end trace 0000000000000000 ]--- Fix this by adding an overflow check when calculating the end of the memory range. Also add an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early. Fixes: 033ddf12bcf5 ("tee: add register user memory") Cc: stable(a)vger.kernel.org Reported-by: Nimish Mishra <neelam.nimish(a)gmail.com> Reported-by: Anirban Chakraborty <ch.anirban00727(a)gmail.com> Reported-by: Debdeep Mukhopadhyay <debdeep.mukhopadhyay(a)gmail.com> Suggested-by: Jerome Forissier <jerome.forissier(a)linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/tee_shm.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index f2b1bcefcadd..f71651021c8d 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -231,15 +231,30 @@ EXPORT_SYMBOL_GPL(tee_shm_alloc_priv_buf); static struct tee_shm * register_shm_helper(struct tee_context *ctx, unsigned long addr, - size_t length, u32 flags, int id) + unsigned long length, u32 flags, int id) { struct tee_device *teedev = ctx->teedev; + unsigned long end_addr; struct tee_shm *shm; unsigned long start; size_t num_pages; void *ret; int rc; + /* Check for overflows, this may be input from user space */ + addr = untagged_addr(addr); + start = rounddown(addr, PAGE_SIZE); + if (check_add_overflow(addr, length, &end_addr)) + return ERR_PTR(-EINVAL); + end_addr = roundup(end_addr, PAGE_SIZE); + if (end_addr < start) + return ERR_PTR(-EINVAL); + num_pages = (end_addr - start) / PAGE_SIZE; + + /* Error out early if no pages are to be registered */ + if (!num_pages) + return ERR_PTR(-EINVAL); + if (!tee_device_get(teedev)) return ERR_PTR(-EINVAL); @@ -261,11 +276,8 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, shm->flags = flags; shm->ctx = ctx; shm->id = id; - addr = untagged_addr(addr); - start = rounddown(addr, PAGE_SIZE); shm->offset = addr - start; shm->size = length; - num_pages = (roundup(addr + length, PAGE_SIZE) - start) / PAGE_SIZE; shm->pages = kcalloc(num_pages, sizeof(*shm->pages), GFP_KERNEL); if (!shm->pages) { ret = ERR_PTR(-ENOMEM); @@ -326,6 +338,9 @@ struct tee_shm *tee_shm_register_user_buf(struct tee_context *ctx, void *ret; int id; + if (!access_ok((void __user *)addr, length)) + return ERR_PTR(-EFAULT); + mutex_lock(&teedev->mutex); id = idr_alloc(&teedev->idr, NULL, 1, 0, GFP_KERNEL); mutex_unlock(&teedev->mutex); -- 2.31.1

3 years, 9 months

3
5
0 0

[PATCH 0/1] tee: Add tee_shm_register_fd

by Olivier Masse

Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a shared memory from a dmabuf file descriptor. Etienne Carriere (1): tee: new ioctl to a register tee_shm from a dmabuf file descriptor drivers/tee/tee_core.c | 38 +++++++++++++++ drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++- include/linux/tee_drv.h | 11 +++++ include/uapi/linux/tee.h | 29 ++++++++++++ 4 files changed, 175 insertions(+), 2 deletions(-) -- 2.25.0

3 years, 9 months

4
7
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE