- OP-TEE - lists.trustedfirmware.org

Linaro OP-TEE Contribution (LOC) monthly meeting December 27

by Jens Wiklander

Hi, The LOC meeting this month is in the middle of the holidays. Let's cancel it since we don't have any urgent topics. Regards, Jens on behalf of the OP-TEE team.

2 years, 10 months

1
0
0 0

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 > >

2 years, 10 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.

2 years, 11 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(-)

2 years, 11 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

2 years, 11 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(-)

2 years, 11 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

2 years, 11 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

2 years, 11 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

2 years, 12 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

2
2
0 0

2025

2024

2023

2022

2021

2020

OP-TEE