- OP-TEE - lists.trustedfirmware.org

by Greg Kroah-Hartman

Now that the driver core allows for struct class to be in read-only memory, we should make all 'class' structures declared at build time placing them into read-only memory, instead of having to be dynamically allocated at runtime. Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Cc: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tee/tee_core.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index 0eb342de0b00..5ddfd5d9ac7f 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -40,7 +40,10 @@ static const uuid_t tee_client_uuid_ns = UUID_INIT(0x58ac9ca0, 0x2086, 0x4683, static DECLARE_BITMAP(dev_mask, TEE_NUM_DEVICES); static DEFINE_SPINLOCK(driver_lock); -static struct class *tee_class; +static const struct class tee_class = { + .name = "tee", +}; + static dev_t tee_devt; struct tee_context *teedev_open(struct tee_device *teedev) @@ -919,7 +922,7 @@ struct tee_device *tee_device_alloc(const struct tee_desc *teedesc, teedesc->flags & TEE_DESC_PRIVILEGED ? "priv" : "", teedev->id - offs); - teedev->dev.class = tee_class; + teedev->dev.class = &tee_class; teedev->dev.release = tee_release_device; teedev->dev.parent = dev; @@ -1112,7 +1115,7 @@ tee_client_open_context(struct tee_context *start, dev = &start->teedev->dev; do { - dev = class_find_device(tee_class, dev, &match_data, match_dev); + dev = class_find_device(&tee_class, dev, &match_data, match_dev); if (!dev) { ctx = ERR_PTR(-ENOENT); break; @@ -1226,10 +1229,10 @@ static int __init tee_init(void) { int rc; - tee_class = class_create("tee"); - if (IS_ERR(tee_class)) { + rc = class_register(&tee_class); + if (rc) { pr_err("couldn't create class\n"); - return PTR_ERR(tee_class); + return rc; } rc = alloc_chrdev_region(&tee_devt, 0, TEE_NUM_DEVICES, "tee"); @@ -1249,8 +1252,7 @@ static int __init tee_init(void) out_unreg_chrdev: unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES); out_unreg_class: - class_destroy(tee_class); - tee_class = NULL; + class_unregister(&tee_class); return rc; } @@ -1259,8 +1261,7 @@ static void __exit tee_exit(void) { bus_unregister(&tee_bus_type); unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES); - class_destroy(tee_class); - tee_class = NULL; + class_unregister(&tee_class); } subsys_initcall(tee_init); -- 2.42.0

2 years, 8 months

2
2
0 0

[PATCH v3] virtio-tee: Reserve device ID 46 for TEE device

by jeshwank

In a virtual environment, an application running in guest VM may want to delegate security sensitive tasks to a Trusted Application (TA) running within 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. A virtual TEE device emulates a TEE within a guest VM. Such a virtual TEE device supports multiple operations such as: VIRTIO_TEE_CMD_OPEN_DEVICE – Open a communication channel with virtio TEE device. VIRTIO_TEE_CMD_CLOSE_DEVICE – Close communication channel with virtio TEE device. VIRTIO_TEE_CMD_GET_VERSION – Get version of virtio TEE. VIRTIO_TEE_CMD_OPEN_SESSION – Open a session to communicate with trusted application running in TEE. VIRTIO_TEE_CMD_CLOSE_SESSION – Close a session to end communication with trusted application running in TEE. VIRTIO_TEE_CMD_INVOKE_FUNC – Invoke a command or function in trusted application running in TEE. VIRTIO_TEE_CMD_CANCEL_REQ – Cancel an ongoing command within TEE. VIRTIO_TEE_CMD_REGISTER_MEM - Register shared memory with TEE. VIRTIO_TEE_CMD_UNREGISTER_MEM - Unregister shared memory from TEE. We would like to reserve device ID 46 for Virtio-TEE device. Signed-off-by: Jeshwanth Kumar <jeshwanthkumar.nk(a)amd.com> Reviewed-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> Reviewed-by: Parav Pandit <parav(a)nvidia.com> Acked-by: Sumit Garg <sumit.garg(a)linaro.org> --- content.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content.tex b/content.tex index 0a62dce..644aa4a 100644 --- a/content.tex +++ b/content.tex @@ -739,6 +739,8 @@ \chapter{Device Types}\label{sec:Device Types} \hline 45 & SPI master \\ \hline +46 & TEE device \\ +\hline \end{tabular} Some of the devices above are unspecified by this document, -- 2.25.1

2 years, 8 months

2
1
0 0

[GIT PULL] AMDTEE fix for v6.6

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small AMDTEE driver fix addressing a possible user-after-free vulnerability. Note that this isn't a usual Arm driver update. This targets AMD instead, but is part of the TEE subsystem. Thanks, Jens The following changes since commit 2dde18cd1d8fac735875f2e4987f11817cc0bc2c: Linux 6.5 (2023-08-27 14:49:51 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/amdtee-fix-for-v6.6 for you to fetch changes up to f4384b3e54ea813868bb81a861bf5b2406e15d8f: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session (2023-10-03 19:13:53 +0200) ---------------------------------------------------------------- AMDTEE fix possible use-after-free ---------------------------------------------------------------- Rijo Thomas (1): tee: amdtee: fix use-after-free vulnerability in amdtee_close_session drivers/tee/amdtee/core.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)

2 years, 8 months

1
0
0 0

[PATCH v2 1/1] tee: amdtee: fix use-after-free vulnerability in amdtee_close_session

by Rijo Thomas

There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Cc: stable(a)vger.kernel.org Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- v2: * Introduced kref_put_mutex() as suggested by Sumit Garg. drivers/tee/amdtee/core.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 372d64756ed6..3c15f6a9e91c 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -217,12 +217,12 @@ static int copy_ta_binary(struct tee_context *ctx, void *ptr, void **ta, return rc; } +/* mutex must be held by caller */ static void destroy_session(struct kref *ref) { struct amdtee_session *sess = container_of(ref, struct amdtee_session, refcount); - mutex_lock(&session_list_mutex); list_del(&sess->list_node); mutex_unlock(&session_list_mutex); kfree(sess); @@ -272,7 +272,8 @@ int amdtee_open_session(struct tee_context *ctx, if (arg->ret != TEEC_SUCCESS) { pr_err("open_session failed %d\n", arg->ret); handle_unload_ta(ta_handle); - kref_put(&sess->refcount, destroy_session); + kref_put_mutex(&sess->refcount, destroy_session, + &session_list_mutex); goto out; } @@ -290,7 +291,8 @@ int amdtee_open_session(struct tee_context *ctx, pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); handle_close_session(ta_handle, session_info); handle_unload_ta(ta_handle); - kref_put(&sess->refcount, destroy_session); + kref_put_mutex(&sess->refcount, destroy_session, + &session_list_mutex); rc = -ENOMEM; goto out; } @@ -331,7 +333,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) handle_close_session(ta_handle, session_info); handle_unload_ta(ta_handle); - kref_put(&sess->refcount, destroy_session); + kref_put_mutex(&sess->refcount, destroy_session, &session_list_mutex); return 0; } -- 2.25.1

2 years, 8 months

3
2
0 0

[PATCH 1/1] tee: amdtee: fix use-after-free vulnerability in amdtee_close_session

by Rijo Thomas

There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and invocation of destroy_session() as a single critical section, so that it is executed atomically. Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver") Cc: stable(a)vger.kernel.org Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- drivers/tee/amdtee/core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 372d64756ed6..04cee03bec9d 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -217,14 +217,13 @@ static int copy_ta_binary(struct tee_context *ctx, void *ptr, void **ta, return rc; } +/* mutex must be held by caller */ static void destroy_session(struct kref *ref) { struct amdtee_session *sess = container_of(ref, struct amdtee_session, refcount); - mutex_lock(&session_list_mutex); list_del(&sess->list_node); - mutex_unlock(&session_list_mutex); kfree(sess); } @@ -272,7 +271,9 @@ int amdtee_open_session(struct tee_context *ctx, if (arg->ret != TEEC_SUCCESS) { pr_err("open_session failed %d\n", arg->ret); handle_unload_ta(ta_handle); + mutex_lock(&session_list_mutex); kref_put(&sess->refcount, destroy_session); + mutex_unlock(&session_list_mutex); goto out; } @@ -290,7 +291,9 @@ int amdtee_open_session(struct tee_context *ctx, pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS); handle_close_session(ta_handle, session_info); handle_unload_ta(ta_handle); + mutex_lock(&session_list_mutex); kref_put(&sess->refcount, destroy_session); + mutex_unlock(&session_list_mutex); rc = -ENOMEM; goto out; } @@ -331,7 +334,9 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) handle_close_session(ta_handle, session_info); handle_unload_ta(ta_handle); + mutex_lock(&session_list_mutex); kref_put(&sess->refcount, destroy_session); + mutex_unlock(&session_list_mutex); return 0; } -- 2.25.1

2 years, 8 months

2
2
0 0

Re: [virtio-dev] [PATCH v2] virtio-tee: Reserve device ID 46 for TEE device

by Sumit Garg

+cc OP-TEE ML On Tue, 26 Sept 2023 at 13:47, Rijo Thomas <Rijo-john.Thomas(a)amd.com> wrote: > > On 9/26/2023 1:19 PM, Sumit Garg wrote: > > On Tue, 26 Sept 2023 at 12:53, Rijo Thomas <Rijo-john.Thomas(a)amd.com> wrote: > >> > >> On 9/26/2023 12:14 PM, Sumit Garg wrote: > >>> +cc Alex > >>> > >>> On Tue, 26 Sept 2023 at 08:16, Jens Wiklander <jens.wiklander(a)linaro.org> wrote: > >>>> > >>>> Hi, > >>>> > >>>> [+cc Arnd] > >>>> > >>>> On Tue, Sep 26, 2023 at 8:00 AM Sumit Garg <sumit.garg(a)linaro.org> wrote: > >>>>> > >>>>> +cc Jens > >>>>> > >>>>>> In a virtual environment, an application running in guest VM may want > >>>>>> to delegate security sensitive tasks to a Trusted Application (TA) > >>>>>> running within 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. > >>>>> > >>>>> I have been exploring this area quite recently with an effort to have a common VIRIO interface which can support different trusted OS implementations. I guess you intend to test it with AMD-TEE, right? Any plans to test it with OP-TEE? As currently we have these two supported upstream. > >>>>> > >> Yes, we have tested with AMD-TEE. We have not yet tested with OP-TEE. Sure, we will try it out. > > > > Glad to hear that. I can help get it tested with OP-TEE as well. > > > > We will test it out internally. Shall let you know in case we need help. > > >> > >>>>> Do you currently have any virtio frontend/backend implementations for this? > >>>>> > >> > >> Yes, we have. Frontend is a Linux virtio-TEE driver, and backend is virtio-TEE device emulated in QEMU. > >> We used the Xen hypervisor. > > > > Can you share corresponding references? I can give it a try using Qemu with KVM. > > > > We will share it in next couple of weeks. We have not yet hosted the code for external consumption. > > >> > >>>>>> > >>>>>> A virtual TEE device emulates a TEE within a guest VM. Such a virtual > >>>>>> TEE device supports multiple operations such as: > >>>>>> > >>>>>> VIRTIO_TEE_CMD_OPEN_DEVICE – Open a communication channel with virtio > >>>>>> TEE device. > >>>>>> VIRTIO_TEE_CMD_CLOSE_DEVICE – Close communication channel with virtio > >>>>>> TEE device. > >>>>>> VIRTIO_TEE_CMD_GET_VERSION – Get version of virtio TEE. > >>>>>> VIRTIO_TEE_CMD_OPEN_SESSION – Open a session to communicate with > >>>>>> trusted application running in TEE. > >>>>>> VIRTIO_TEE_CMD_CLOSE_SESSION – Close a session to end communication > >>>>>> with trusted application running in TEE. > >>>>>> VIRTIO_TEE_CMD_INVOKE_FUNC – Invoke a command or function in trusted > >>>>>> application running in TEE. > >>>>>> VIRTIO_TEE_CMD_CANCEL_REQ – Cancel an ongoing command within TEE. > >>>>>> > >>>>> > >>>>> How about shared memory support? We would like to register guest pages with the trusted OS. > >> We have a command VIRTIO_TEE_CMD_REGISTER_MEM for registering shared memory buffer with Trusted OS. > > > > I suppose the commit message has to be appended then. Do you have the > > draft virtio-tee device specification ready for review? I would be > > interested to review that. > > > > Yes, the command is missed out in the commit message. With the commit message updated to include support for shared memory, feel free to add: Acked-by: Sumit Garg <sumit.garg(a)linaro.org> > > We are in the process of preparing virtio-tee device specification. We will be sending it out to this > list. I would also suggest you to CC: op-tee(a)lists.trustedfirmware.org for review. > > >> > >> In this command, the guest pages are copied into a shadow buffer in the host OS. And this shadow > >> buffer is mapped with Trusted OS. So, buffer-copy is involved. > >> > >> One limitation, that we had was that the guest pages were non-contiguous. So, the number of physical > >> pages that had to be mapped with Trusted OS was exceeding 64 entries when we were testing out the > >> registering of guest pages. AMD-TEE Trusted OS can map a physically non-contiguous buffer, but the > >> number of sg entries for such a buffer must be less than 64. So, we resorted to using a shadow buffer > >> that is allocated within host, and gets mapped with Trusted OS. > > > > I don't think OP-TEE OS has such a limitation on non-contiguous pages. > > So I would suggest you to keep VIRTIO_TEE_CMD_REGISTER_MEM as part of > > the ABI. It can be an optional feature for a particular trusted OS > > implementation to support. > > > > Currently, the reg_mem (register memory) control is dictated by a flag in virtio-tee qemu code. This flag > for our testing was hard-coded as false. We will enhance our code, so that it is configurable. The value > of reg_mem shall be set to true/false depending upon whether the underlying TEE driver reports TEE_GEN_CAP_REG_MEM. Sounds good to me. -Sumit > > Thanks, > Rijo > > > -Sumit > > > >> > >> Thanks, > >> Rijo > >> > >>>> > >>>> Coincidently Arnd and I (among others) discussed this in person last > >>>> week and the conclusion was that only temporary shared memory is > >>>> possible with virtio. So the shared memory has to be set up and torn > >>>> down by the host during each operation, typically open-session or > >>>> invoke-func. > >>> > >>> Agree as I was part of those discussions. But I would like to > >>> understand the reasoning behind it. Is there any restriction by VIRTIO > >>> specification that we can't register guest page PAs to a device (TEE > >>> in our case) to allow for zero copy transfers? > >>> > >>> Alex mentioned some references to virtio GPU device. I suppose I need > >>> to dive into its implementation to see if there are any similarities > >>> to our use-case. > >>> > >>>> That might not be optimal if trying to maximize > >>>> performance, but it is portable. > >>> > >>> IMO, the ABI should be flexible enough to support a TEE with optimum > >>> performance. > >>> > >>> -Sumit > >>> > >>>> > >>>> Cheers, > >>>> Jens > >>>> > >>>>> > >>>>> -Sumit > >>>>> > >>>>>> We would like to reserve device ID 46 for Virtio-TEE device. > >>>>>> > >>>>>> Signed-off-by: Jeshwanth Kumar <jeshwanthkumar.nk(a)amd.com> > >>>>>> --- > >>>>>> content.tex | 2 ++ > >>>>>> 1 file changed, 2 insertions(+) > >>>>>> > >>>>>> diff --git a/content.tex b/content.tex > >>>>>> index 0a62dce..644aa4a 100644 > >>>>>> --- a/content.tex > >>>>>> +++ b/content.tex > >>>>>> @@ -739,6 +739,8 @@ \chapter{Device Types}\label{sec:Device Types} > >>>>>> \hline > >>>>>> 45 & SPI master \\ > >>>>>> \hline > >>>>>> +46 & TEE device \\ > >>>>>> +\hline > >>>>>> \end{tabular} > >>>>>> > >>>>>> Some of the devices above are unspecified by this document,

2 years, 9 months

2
1
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting September 26

by Jens Wiklander

Hi Today Tuesday, September 26 it's time for another LOC monthly meeting. Sorry for the short notice. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I have a few items for the agenda: - Firmware handoff in OP-TEE https://github.com/OP-TEE/optee_os/pull/6308 - We've started to upstream a few PRs that will require bumping the major version to 4 Any other topics? Thanks, Jens

2 years, 9 months

1
0
0 0

TA access to its own checksum

by Robert Delien

Hi, For legislative purposes, one of our Trusted Applications needs to show a checksum to the end-user on our secure screen, to allow verification. Albeit a bit unconventional use of it, we thought that the TA's own checksum would be ideal for that, but we're having difficulties figuring how to access that, if at all possible. So I have to turn to you guys here: Is there any way for a TA to access its own checksum? And if yes, could somebody please give me some pointers on how to do this? With kind regards, Robert. -- DISCLAIMER De informatie, verzonden in of met dit e-mailbericht, is vertrouwelijk en uitsluitend voor de geadresseerde(n) bestemd. Het gebruik van de informatie in dit bericht, de openbaarmaking, vermenigvuldiging, verspreiding en|of verstrekking daarvan aan derden is niet toegestaan. Gebruik van deze informatie door anderen dan geadresseerde(n) is strikt verboden. Aan deze informatie kunnen geen rechten worden ontleend. U wordt verzocht bij onjuiste adressering de afzender direct te informeren door het bericht te retourneren en het bericht uit uw computersysteem te verwijderen.

2 years, 9 months

3
2
0 0

[PATCH -next] tee: Remove unused declarations

by Yue Haibing

Commit 4fb0a5eb364d ("tee: add OP-TEE driver") declared but never implemented optee_supp_read()/optee_supp_write(). Commit 967c9cca2cc5 ("tee: generic TEE subsystem") never implemented tee_shm_init(). Signed-off-by: Yue Haibing <yuehaibing(a)huawei.com> --- drivers/tee/optee/optee_private.h | 2 -- drivers/tee/tee_private.h | 2 -- 2 files changed, 4 deletions(-) diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 72685ee0d53f..6bb5cae09688 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -238,8 +238,6 @@ int optee_notif_send(struct optee *optee, u_int key); u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct tee_param *param); -int optee_supp_read(struct tee_context *ctx, void __user *buf, size_t len); -int optee_supp_write(struct tee_context *ctx, void __user *buf, size_t len); void optee_supp_init(struct optee_supp *supp); void optee_supp_uninit(struct optee_supp *supp); void optee_supp_release(struct optee_supp *supp); diff --git a/drivers/tee/tee_private.h b/drivers/tee/tee_private.h index 409cadcc1cff..754e11dcb240 100644 --- a/drivers/tee/tee_private.h +++ b/drivers/tee/tee_private.h @@ -47,8 +47,6 @@ struct tee_device { struct tee_shm_pool *pool; }; -int tee_shm_init(void); - int tee_shm_get_fd(struct tee_shm *shm); bool tee_device_get(struct tee_device *teedev); -- 2.34.1

2 years, 9 months

3
2
0 0

[GIT PULL] TEE fix for v6.6

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small fix that removes a few unused function declarations in the TEE subsystem. Thanks, Jens The following changes since commit 2dde18cd1d8fac735875f2e4987f11817cc0bc2c: Linux 6.5 (2023-08-27 14:49:51 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git/ tags/optee-for-for-v6.6 for you to fetch changes up to 069969d6c5264d2348fd6cf0cedc00fd87ff3cee: tee: Remove unused declarations (2023-09-13 08:16:24 +0200) ---------------------------------------------------------------- Remove a few unused declarations in TEE subsystem ---------------------------------------------------------------- Yue Haibing (1): tee: Remove unused declarations drivers/tee/optee/optee_private.h | 2 -- drivers/tee/tee_private.h | 2 -- 2 files changed, 4 deletions(-)

2 years, 9 months

1
0
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
0
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, To all TF maillists in case all aren't yet aware. We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. I've attached a recent screenshot from the #general channel as a sample of the interface and usages. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
0
0 0

[PATCH] tee: amdtee: add support for use of cma region

by Devaraj Rangasamy

In systems with low memory configuration, memory gets fragmented easily, and any bigger size contiguous memory allocations are likely to fail. Contiguous Memory Allocator (CMA) is used to overcome this limitation, and to guarantee memory allocations. This patch adds support for CMA area exclusive to amdtee. The support can be enabled if kernel have CONFIG_CMA enabled. The size can be set via the AMDTEE_CMA_SIZE config option at compile time or with the "amdtee_cma" kernel parameter. (e.g. "amdtee_cma=32 for 32MB"). Also, cma zone is utilized only for buffer allocation bigger than 64k bytes. When such allocation fails, there is a fallback to the buddy allocator. Since CMA requires a boot time initialization, it is enabled only when amdtee is built as an inbuilt driver. Signed-off-by: Devaraj Rangasamy <Devaraj.Rangasamy(a)amd.com> Co-developed-by: SivaSangeetha SK <SivaSangeetha.SK(a)amd.com> Signed-off-by: SivaSangeetha SK <SivaSangeetha.SK(a)amd.com> Reviewed-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- .../admin-guide/kernel-parameters.txt | 7 ++ arch/x86/include/asm/setup.h | 6 ++ arch/x86/kernel/setup.c | 2 + drivers/tee/amdtee/Kconfig | 9 +++ drivers/tee/amdtee/Makefile | 1 + drivers/tee/amdtee/amdtee_private.h | 6 +- drivers/tee/amdtee/core.c | 6 +- drivers/tee/amdtee/shm_pool.c | 32 ++++++-- drivers/tee/amdtee/shm_pool_cma.c | 78 +++++++++++++++++++ drivers/tee/amdtee/shm_pool_cma.h | 38 +++++++++ 10 files changed, 176 insertions(+), 9 deletions(-) create mode 100644 drivers/tee/amdtee/shm_pool_cma.c create mode 100644 drivers/tee/amdtee/shm_pool_cma.h diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 722b6eca2e93..5e38423f3d53 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -363,6 +363,13 @@ selects a performance level in this range and appropriate to the current workload. + amdtee_cma=nn [HW,TEE] + Sets the memory size reserved for contiguous memory + allocations, to be used by amdtee device driver. + Value is in MB and can range from 4 to 128 (MBs) + CMA will be active only when CMA is enabled, and amdtee is + built as inbuilt driver, and not loaded as module. + amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: <a>,<b> diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h index f3495623ac99..bb5e4b7134a2 100644 --- a/arch/x86/include/asm/setup.h +++ b/arch/x86/include/asm/setup.h @@ -66,6 +66,12 @@ extern void x86_ce4100_early_setup(void); static inline void x86_ce4100_early_setup(void) { } #endif +#if IS_BUILTIN(CONFIG_AMDTEE) && IS_ENABLED(CONFIG_CMA) +void amdtee_cma_reserve(void); +#else +static inline void amdtee_cma_reserve(void) { } +#endif + #ifndef _SETUP #include <asm/espfix.h> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index fd975a4a5200..e73433af3bfa 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1223,6 +1223,8 @@ void __init setup_arch(char **cmdline_p) initmem_init(); dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT); + amdtee_cma_reserve(); + if (boot_cpu_has(X86_FEATURE_GBPAGES)) hugetlb_cma_reserve(PUD_SHIFT - PAGE_SHIFT); diff --git a/drivers/tee/amdtee/Kconfig b/drivers/tee/amdtee/Kconfig index 191f9715fa9a..5843c739a7b8 100644 --- a/drivers/tee/amdtee/Kconfig +++ b/drivers/tee/amdtee/Kconfig @@ -6,3 +6,12 @@ config AMDTEE depends on CRYPTO_DEV_SP_PSP && CRYPTO_DEV_CCP_DD help This implements AMD's Trusted Execution Environment (TEE) driver. + +config AMDTEE_CMA_SIZE + int "Size of Memory in MiB reserved in CMA for AMD-TEE" + default "0" + depends on CMA && (AMDTEE=y) + help + Specify the default amount of memory in MiB reserved in CMA for AMD-TEE driver + Any amdtee shm buffer allocation larger than 64k will allocate memory from the CMA + The default can be overridden with the kernel commandline parameter "amdtee_cma". \ No newline at end of file diff --git a/drivers/tee/amdtee/Makefile b/drivers/tee/amdtee/Makefile index ff1485266117..a197839cfcf3 100644 --- a/drivers/tee/amdtee/Makefile +++ b/drivers/tee/amdtee/Makefile @@ -3,3 +3,4 @@ obj-$(CONFIG_AMDTEE) += amdtee.o amdtee-objs += core.o amdtee-objs += call.o amdtee-objs += shm_pool.o +amdtee-objs += shm_pool_cma.o diff --git a/drivers/tee/amdtee/amdtee_private.h b/drivers/tee/amdtee/amdtee_private.h index 6d0f7062bb87..9ba47795adb6 100644 --- a/drivers/tee/amdtee/amdtee_private.h +++ b/drivers/tee/amdtee/amdtee_private.h @@ -87,11 +87,13 @@ struct shmem_desc { * struct amdtee_shm_data - Shared memory data * @kaddr: Kernel virtual address of shared memory * @buf_id: Buffer id of memory mapped by TEE_CMD_ID_MAP_SHARED_MEM + * @is_cma: Indicates whether memory is allocated from cma region or not */ struct amdtee_shm_data { struct list_head shm_node; void *kaddr; u32 buf_id; + bool is_cma; }; /** @@ -145,9 +147,9 @@ int amdtee_invoke_func(struct tee_context *ctx, int amdtee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session); -int amdtee_map_shmem(struct tee_shm *shm); +int amdtee_map_shmem(struct tee_shm *shm, bool is_cma); -void amdtee_unmap_shmem(struct tee_shm *shm); +void amdtee_unmap_shmem(struct tee_shm *shm, bool *is_cma); int handle_load_ta(void *data, u32 size, struct tee_ioctl_open_session_arg *arg); diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index 372d64756ed6..448802dccf13 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -336,7 +336,7 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) return 0; } -int amdtee_map_shmem(struct tee_shm *shm) +int amdtee_map_shmem(struct tee_shm *shm, bool is_cma) { struct amdtee_context_data *ctxdata; struct amdtee_shm_data *shmnode; @@ -368,6 +368,7 @@ int amdtee_map_shmem(struct tee_shm *shm) shmnode->kaddr = shm->kaddr; shmnode->buf_id = buf_id; + shmnode->is_cma = is_cma; ctxdata = shm->ctx->data; mutex_lock(&ctxdata->shm_mutex); list_add(&shmnode->shm_node, &ctxdata->shm_list); @@ -378,7 +379,7 @@ int amdtee_map_shmem(struct tee_shm *shm) return 0; } -void amdtee_unmap_shmem(struct tee_shm *shm) +void amdtee_unmap_shmem(struct tee_shm *shm, bool *is_cma) { struct amdtee_context_data *ctxdata; struct amdtee_shm_data *shmnode; @@ -395,6 +396,7 @@ void amdtee_unmap_shmem(struct tee_shm *shm) mutex_lock(&ctxdata->shm_mutex); list_for_each_entry(shmnode, &ctxdata->shm_list, shm_node) if (buf_id == shmnode->buf_id) { + *is_cma = shmnode->is_cma; list_del(&shmnode->shm_node); kfree(shmnode); break; diff --git a/drivers/tee/amdtee/shm_pool.c b/drivers/tee/amdtee/shm_pool.c index f0303126f199..9aad401387be 100644 --- a/drivers/tee/amdtee/shm_pool.c +++ b/drivers/tee/amdtee/shm_pool.c @@ -7,19 +7,30 @@ #include <linux/tee_drv.h> #include <linux/psp.h> #include "amdtee_private.h" +#include "shm_pool_cma.h" static int pool_op_alloc(struct tee_shm_pool *pool, struct tee_shm *shm, size_t size, size_t align) { unsigned int order = get_order(size); unsigned long va; + bool is_cma = false; int rc; /* * Ignore alignment since this is already going to be page aligned * and there's no need for any larger alignment. */ - va = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order); + + /* if CMA is available, use it for higher order allocation */ + if (amdtee_get_cma_size() && order > 6) + va = amdtee_alloc_from_cma(shm, order); + + if (va) + is_cma = true; + else + va = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order); + if (!va) return -ENOMEM; @@ -28,9 +39,13 @@ static int pool_op_alloc(struct tee_shm_pool *pool, struct tee_shm *shm, shm->size = PAGE_SIZE << order; /* Map the allocated memory in to TEE */ - rc = amdtee_map_shmem(shm); + rc = amdtee_map_shmem(shm, is_cma); if (rc) { - free_pages(va, order); + if (is_cma) + amdtee_free_from_cma(shm); + else + free_pages(va, order); + shm->kaddr = NULL; return rc; } @@ -40,9 +55,16 @@ static int pool_op_alloc(struct tee_shm_pool *pool, struct tee_shm *shm, static void pool_op_free(struct tee_shm_pool *pool, struct tee_shm *shm) { + bool is_cma = false; + /* Unmap the shared memory from TEE */ - amdtee_unmap_shmem(shm); - free_pages((unsigned long)shm->kaddr, get_order(shm->size)); + amdtee_unmap_shmem(shm, &is_cma); + + if (is_cma) + amdtee_free_from_cma(shm); + else + free_pages((unsigned long)shm->kaddr, get_order(shm->size)); + shm->kaddr = NULL; } diff --git a/drivers/tee/amdtee/shm_pool_cma.c b/drivers/tee/amdtee/shm_pool_cma.c new file mode 100644 index 000000000000..99dda9adb1c6 --- /dev/null +++ b/drivers/tee/amdtee/shm_pool_cma.c @@ -0,0 +1,78 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright 2023 Advanced Micro Devices, Inc. + */ + +#if IS_BUILTIN(CONFIG_AMDTEE) && IS_ENABLED(CONFIG_CMA) + +#define pr_fmt(fmt) "%s: " fmt, __func__ + +#include <linux/cma.h> +#include <linux/mm.h> +#include <linux/tee_drv.h> +#include "shm_pool_cma.h" + +static struct cma *amdtee_cma; +unsigned long amdtee_cma_size __initdata = CONFIG_AMDTEE_CMA_SIZE * SZ_1M; + +static int __init early_parse_amdtee_cma(char *p) +{ + int cmd_size; + + if (!p) + return 1; + + cmd_size = memparse(p, NULL); + if (cmd_size >= 4 && cmd_size <= 256) + amdtee_cma_size = cmd_size * SZ_1M; + else + pr_err("invalid amdtee_cma size: %lu\n", amdtee_cma_size); + + return 0; +} +early_param("amdtee_cma", early_parse_amdtee_cma); + +void __init amdtee_cma_reserve(void) +{ + int ret; + + ret = cma_declare_contiguous(0, amdtee_cma_size, 0, 0, 0, false, "amdtee", &amdtee_cma); + if (ret) + pr_err("Failed to reserve CMA region of size %lu\n", amdtee_cma_size); + else + pr_info("Reserved %lu bytes CMA for amdtee\n", amdtee_cma_size); +} + +unsigned long amdtee_alloc_from_cma(struct tee_shm *shm, unsigned int order) +{ + struct page *page = NULL; + unsigned long va = 0; + int nr_pages = 0; + + if (amdtee_cma) { + nr_pages = 1 << order; + page = cma_alloc(amdtee_cma, nr_pages, 0, false); + if (page) + va = (unsigned long)page_to_virt(page); + else + pr_debug("failed to allocate from CMA region\n"); + } else { + pr_debug("CMA region is not available\n"); + } + return va; +} + +void amdtee_free_from_cma(struct tee_shm *shm) +{ + struct page *page; + int nr_pages = 0; + + if (amdtee_cma) { + nr_pages = 1 << get_order(shm->size); + page = virt_to_page(shm->kaddr); + cma_release(amdtee_cma, page, nr_pages); + } else { + pr_err("CMA region is not available\n"); + } +} +#endif /* IS_BUILTIN(CONFIG_AMDTEE) && IS_ENABLED(CONFIG_CMA) */ diff --git a/drivers/tee/amdtee/shm_pool_cma.h b/drivers/tee/amdtee/shm_pool_cma.h new file mode 100644 index 000000000000..d1cde11cbede --- /dev/null +++ b/drivers/tee/amdtee/shm_pool_cma.h @@ -0,0 +1,38 @@ +/* SPDX-License-Identifier: MIT */ + +/* + * Copyright 2023 Advanced Micro Devices, Inc. + */ + +#ifndef SHM_POOL_CMA_H +#define SHM_POOL_CMA_H + +#if IS_BUILTIN(CONFIG_AMDTEE) && IS_ENABLED(CONFIG_CMA) + +extern unsigned long amdtee_cma_size; + +static inline unsigned long amdtee_get_cma_size(void) +{ + return amdtee_cma_size; +} + +unsigned long amdtee_alloc_from_cma(struct tee_shm *shm, unsigned int order); + +void amdtee_free_from_cma(struct tee_shm *shm); + +#else /* IS_BUILTIN(CONFIG_AMDTEE) && IS_ENABLED(CONFIG_CMA) */ + +static inline unsigned long amdtee_get_cma_size(void) +{ + return 0; +} + +static inline unsigned long amdtee_alloc_from_cma(struct tee_shm *shm, unsigned int order) +{ + return 0; +} + +static inline void amdtee_free_from_cma(struct tee_shm *shm) { } + +#endif /* IS_BUILTIN(CONFIG_AMDTEE) && IS_ENABLED(CONFIG_CMA) */ +#endif /* SHM_POOL_CMA_H */ -- 2.25.1

2 years, 9 months

4
6
0 0

Optee + OpenSSH/OpenSSL

by Hareesh Das Ulleri

Hello all, We are started using Op-tee in our project. Since we are new to Op-tee, could someone please confirm whether anyone has already tried below in their project or is it possible to use along with OpenSSH/OpenSSL ? What we try to accomplish is: application/sshd -> openssl (libcrypto/provider) -> Optee (client/TA) -> (HW or SW cipher algorithm) for data encryption/decryption. Thanks, Hareesh

2 years, 9 months

6
7
0 0

[RFC, PATCH 0/1] Replay Protected Memory Block (RPMB) driver

by Shyam Saini

Hi everyone, This is yet another attempt to come up with an RPMB API for the kernel. This patch is based on patch 1 of last submission except few minor changes. The last discussion of this was in the thread: Subject: [PATCH v2 1/4] rpmb: add Replay Protected Memory Block (RPMB) subsystem Date: Tue, 5 Apr 2022 10:37:56 +0100 [thread overview] Message-ID: <20220405093759.1126835-2-alex.bennee(a)linaro.org> The patch provides a simple RPMB driver. This is a RFC version and this single driver can't be used by its own. It would require further work to make use of API's provided by this driver. Changes since the last posting: drop RPMB char driver drop virtio rpmb frontend driver drop rpmb: add RPBM access tool Rename get_write_count to get_write_counter Make return type for rpmb_set_key() function explicit Alex Bennée (1): rpmb: add Replay Protected Memory Block (RPMB) driver MAINTAINERS | 7 + drivers/Kconfig | 1 + drivers/Makefile | 2 + drivers/rpmb/Kconfig | 11 ++ drivers/rpmb/Makefile | 7 + drivers/rpmb/core.c | 439 ++++++++++++++++++++++++++++++++++++++++++ include/linux/rpmb.h | 182 +++++++++++++++++ 7 files changed, 649 insertions(+) create mode 100644 drivers/rpmb/Kconfig create mode 100644 drivers/rpmb/Makefile create mode 100644 drivers/rpmb/core.c create mode 100644 include/linux/rpmb.h -- 2.34.1

2 years, 10 months

9
20
0 0

[PATCH] KEYS: trusted: tee: use tee_shm_register_alloc_buf()

by Jens Wiklander

Prior to this patch was trusted_tee_seal() and trusted_tee_get_random() relying on tee_shm_register_kernel_buf() to share memory with the TEE. Depending on the memory allocation pattern the pages holding the registered buffers overlap with other buffers also shared with the TEE. The OP-TEE driver using the old SMC based ABI permits overlapping shared buffers, but with the new FF-A based ABI each physical page may only be registered once. Fix this problem by allocating a temporary page aligned shared memory buffer to be used as a bounce buffer for the needed data buffers. Since TEE trusted keys doesn't depend on registered shared memory support any longer remove that explicit dependency when opening a context to the TEE. Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- security/keys/trusted-keys/trusted_tee.c | 68 +++++++++++++----------- 1 file changed, 36 insertions(+), 32 deletions(-) diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c index ac3e270ade69..3085343c489a 100644 --- a/security/keys/trusted-keys/trusted_tee.c +++ b/security/keys/trusted-keys/trusted_tee.c @@ -8,6 +8,7 @@ #include <linux/err.h> #include <linux/key-type.h> +#include <linux/minmax.h> #include <linux/module.h> #include <linux/slab.h> #include <linux/string.h> @@ -65,38 +66,37 @@ static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob) int ret; struct tee_ioctl_invoke_arg inv_arg; struct tee_param param[4]; - struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL; + struct tee_shm *shm; + uint8_t *buf; memset(&inv_arg, 0, sizeof(inv_arg)); memset(&param, 0, sizeof(param)); - reg_shm_in = tee_shm_register_kernel_buf(pvt_data.ctx, p->key, - p->key_len); - if (IS_ERR(reg_shm_in)) { - dev_err(pvt_data.dev, "key shm register failed\n"); - return PTR_ERR(reg_shm_in); + shm = tee_shm_alloc_kernel_buf(pvt_data.ctx, + p->key_len + sizeof(p->blob)); + if (IS_ERR(shm)) { + dev_err(pvt_data.dev, "key shm alloc failed\n"); + return PTR_ERR(shm); } - - reg_shm_out = tee_shm_register_kernel_buf(pvt_data.ctx, p->blob, - sizeof(p->blob)); - if (IS_ERR(reg_shm_out)) { - dev_err(pvt_data.dev, "blob shm register failed\n"); - ret = PTR_ERR(reg_shm_out); + buf = tee_shm_get_va(shm, 0); + if (IS_ERR(buf)) { + ret = PTR_ERR(buf); goto out; } + memcpy(buf, p->key, p->key_len); inv_arg.func = TA_CMD_SEAL; inv_arg.session = pvt_data.session_id; inv_arg.num_params = 4; param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT; - param[0].u.memref.shm = reg_shm_in; + param[0].u.memref.shm = shm; param[0].u.memref.size = p->key_len; param[0].u.memref.shm_offs = 0; param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT; - param[1].u.memref.shm = reg_shm_out; + param[1].u.memref.shm = shm; param[1].u.memref.size = sizeof(p->blob); - param[1].u.memref.shm_offs = 0; + param[1].u.memref.shm_offs = p->key_len; ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param); if ((ret < 0) || (inv_arg.ret != 0)) { @@ -104,14 +104,13 @@ static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob) inv_arg.ret); ret = -EFAULT; } else { + memcpy(p->blob, buf + p->key_len, + min(param[1].u.memref.size, sizeof(p->blob))); p->blob_len = param[1].u.memref.size; } out: - if (reg_shm_out) - tee_shm_free(reg_shm_out); - if (reg_shm_in) - tee_shm_free(reg_shm_in); + tee_shm_free(shm); return ret; } @@ -166,11 +165,9 @@ static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob) p->key_len = param[1].u.memref.size; } + tee_shm_free(reg_shm_out); out: - if (reg_shm_out) - tee_shm_free(reg_shm_out); - if (reg_shm_in) - tee_shm_free(reg_shm_in); + tee_shm_free(reg_shm_in); return ret; } @@ -183,15 +180,21 @@ static int trusted_tee_get_random(unsigned char *key, size_t key_len) int ret; struct tee_ioctl_invoke_arg inv_arg; struct tee_param param[4]; - struct tee_shm *reg_shm = NULL; + struct tee_shm *shm; + void *buf; memset(&inv_arg, 0, sizeof(inv_arg)); memset(&param, 0, sizeof(param)); - reg_shm = tee_shm_register_kernel_buf(pvt_data.ctx, key, key_len); - if (IS_ERR(reg_shm)) { - dev_err(pvt_data.dev, "key shm register failed\n"); - return PTR_ERR(reg_shm); + shm = tee_shm_alloc_kernel_buf(pvt_data.ctx, key_len); + if (IS_ERR(shm)) { + dev_err(pvt_data.dev, "key shm alloc failed\n"); + return PTR_ERR(shm); + } + buf = tee_shm_get_va(shm, 0); + if (IS_ERR(buf)) { + ret = PTR_ERR(buf); + goto out; } inv_arg.func = TA_CMD_GET_RANDOM; @@ -199,7 +202,7 @@ static int trusted_tee_get_random(unsigned char *key, size_t key_len) inv_arg.num_params = 4; param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT; - param[0].u.memref.shm = reg_shm; + param[0].u.memref.shm = shm; param[0].u.memref.size = key_len; param[0].u.memref.shm_offs = 0; @@ -209,18 +212,19 @@ static int trusted_tee_get_random(unsigned char *key, size_t key_len) inv_arg.ret); ret = -EFAULT; } else { + memcpy(key, buf, min(param[0].u.memref.size, key_len)); ret = param[0].u.memref.size; } - tee_shm_free(reg_shm); +out: + tee_shm_free(shm); return ret; } static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data) { - if (ver->impl_id == TEE_IMPL_ID_OPTEE && - ver->gen_caps & TEE_GEN_CAP_REG_MEM) + if (ver->impl_id == TEE_IMPL_ID_OPTEE) return 1; else return 0; -- 2.34.1

2 years, 10 months

2
11
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting August 22

by Jens Wiklander

Hi, Time flies, on Tuesday, August 22 it's for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I'm happy to report that the Xen patches needed to run OP-TEE with FF-A have just been merged [1] and will be included in the next Xen release. With this, we may need to focus more on for how long we may hog the CPU with non-secure interrupts masked. [1] https://patchew.org/Xen/20230731121536.934239-1-jens.wiklander@linaro.org/#… Any other topics? Thanks, Jens

2 years, 10 months

1
0
0 0

Run OP-TEE on Morello kernel issue

by Menna Mahmoud

Hi All, I have an issue with running OP-TEE on the Morello kernel, I posted it here: https://github.com/OP-TEE/optee_os/issues/6244 Can anyone help me? Thanks in advance, Menna

2 years, 10 months

1
0
0 0

tpm2 device fail on u-boot

by Ruth Glushkin

Hi, I have u-boot based on u-boot 2021.04 I have configuration with fTPM of Microsoft enabled. I have a EVB board with Nuvoton chip. OPTee-OS is based on latest 3.22 upstream version with Nuvoton npcm platform configuration. If I take OPTee-OS without reading HUK from our PCR0 field from non-secured memory, the command works fine. If I add reading HUK, the command fails. Here is the error log: - U-Boot>tpm2 device optee optee: OP-TEE: revision 3.22 (a012b992) I/TC: Reserved shared memory is enabled I/TC: Dynamic shared memory is enabled I/TC: Normal World virtualization support is disabled I/TC: Asynchronous notifications are disabled E/TC:0 0 std_entry_with_parg:235 Bad arg address 0x7fce2000 Couldn't set TPM 0 (rc = 1) - All other commands of tpm2 that are not connected to fTPM works OK. After loading Linux, xtest works OK. Could you please help me? Thank you in advance, Margarita Glushkin

2 years, 10 months

2
2
0 0

[PATCH v7 0/5] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v6 -> v7 Patch #1-#4 are not updated. Patch #5 is added into this series, original patch is here: https://lore.kernel.org/all/20230609094532.562934-1-ilias.apalodimas@linaro… There are two issues in the v6 series and v7 series addresses those. 1) efivar ops is not restored when the tee-supplicant daemon terminates. -> As the following patch says, user must remove the device before terminating tee-supplicant daemon. https://lore.kernel.org/all/20230728134832.326467-1-sumit.garg@linaro.org/ 2) cause panic when someone remounts the efivarfs as RW even if SetVariable is not supported -> The fifth patch addresses this issue. "[PATCH v7 5/5] efivarfs: force RO when remounting if SetVariable is not supported" Changelog: v5 -> v6 - new patch #4 is added in this series, #1-#3 patches are unchanged. automatically update super block flag when the efivarops support SetVariable runtime service, so that user does not need to manually remount the efivarfs as RW. v4 -> v5 - rebase to efi-next based on v6.4-rc1 - set generic_ops.query_variable_info, it works as expected as follows. $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Ilias Apalodimas (1): efivarfs: force RO when remounting if SetVariable is not supported Masahisa Kojima (4): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver efivarfs: automatically update super block flag drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 18 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++ drivers/firmware/efi/vars.c | 8 + fs/efivarfs/super.c | 45 ++ include/linux/efi.h | 12 + 8 files changed, 973 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c base-commit: 2e28a798c3092ea42b968fa16ac835969d124898 -- 2.30.2

2 years, 10 months

5
12
0 0

[PATCH v6 0/4] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v5 -> v6 - new patch #4 is added in this series, #1-#3 patches are unchanged. automatically update super block flag when the efivarops support SetVariable runtime service, so that user does not need to manually remount the efivarfs as RW. v4 -> v5 - rebase to efi-next based on v6.4-rc1 - set generic_ops.query_variable_info, it works as expected as follows. $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Masahisa Kojima (4): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver efivarfs: automatically update super block flag drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 18 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++ drivers/firmware/efi/vars.c | 8 + fs/efivarfs/super.c | 33 + include/linux/efi.h | 12 + 8 files changed, 961 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c base-commit: d0a1865cf7e2211d9227592ef4141f4632e33908 -- 2.30.2

2 years, 11 months

3
16
0 0

OP-TEE 3.22.0 has been released

by Joakim Bech

Hi, I'm pleased to announce that OP-TEE version 3.22.0 is now available. The list of changes can be found in the changelog [1]. The branch for stable can be found here [2]. Tested platforms in this release can be found here [3]. Many thanks to everyone who has contributed in any form to this release. Let me also highlight that because many people are on vacation over the summer, we cancelled the Linaro OP-TEE call for the month of July. Having said that, we have coverage for maintenance tasks and security issues. However, due to the reduced workforce, getting attention for reviewing and merging may take a little longer in the coming weeks. [1] https://github.com/OP-TEE/optee_os/blob/master/CHANGELOG.md [2] https://github.com/OP-TEE/manifest/tree/3.22.0 [3] https://github.com/OP-TEE/optee_os/commit/001ace6655dd6bb9cbe31aa31b4ba6974… -- Regards, Joakim

2 years, 11 months

2
1
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

Hi, Jens, The PR has been updated as requested. https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年7月3日(星期一) 15:20 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: core: fix fragmented memory retrieve Hi Yuye, On Mon, Jul 3, 2023 at 8:30 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > Hi, Jens, > > The previous fix was based on ffa_mem_transaction with ffa version 1.0, > now optee and Hafnium have updated ffa_mem_transaction to ffa 1.1. > But optee-driver in linaro-swg/linux seems to be using ffa version 1.0, > which causes incorrect data reading when the driver is doing mem_share to Hafnium. > I need to debug my previous code. > When will optee-driver synchronize this version change? Updating the SPMC version in the SPMC manifest should fix the issue of mismatching versions. By the way, I've started to update my QEMU S-EL2 setup to use upstream only. I'll propose updates for the manifest and build gits to be merged after the upcoming OP-TEE release. Cheers, Jens > > Regards, > Yuye. > > ------------------------------------------------------------------ > 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> > 发送时间：2023年6月28日(星期三) 17:54 > 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> > 抄送：op-tee <op-tee(a)lists.trustedfirmware.org> > 主题：Re: core: fix fragmented memory retrieve > > Hi Yuye, > > On Wed, Jun 28, 2023 at 11:50 AM 梅建强(禹夜) > <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > > > > > > Hi, Jens, > > > > Sorry for forgetting to revise the PR in time, because my github email changed so I haven't received any comments. > > Could you help me reopen the PR since I don't have the right? I will re-fix the problem as requested. > > Thanks. > > https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > > > I've reopened it. > > Cheers, > Jens

2 years, 11 months

1
0
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

Hi, Jens, The previous fix was based on ffa_mem_transaction with ffa version 1.0, now optee and Hafnium have updated ffa_mem_transaction to ffa 1.1. But optee-driver in linaro-swg/linux seems to be using ffa version 1.0, which causes incorrect data reading when the driver is doing mem_share to Hafnium. I need to debug my previous code. When will optee-driver synchronize this version change? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年6月28日(星期三) 17:54 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: core: fix fragmented memory retrieve Hi Yuye, On Wed, Jun 28, 2023 at 11:50 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > Hi, Jens, > > Sorry for forgetting to revise the PR in time, because my github email changed so I haven't received any comments. > Could you help me reopen the PR since I don't have the right? I will re-fix the problem as requested. > Thanks. > https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > I've reopened it. Cheers, Jens

2 years, 11 months

2
1
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

Hi, Jens Since the optee driver has not been updated to ffa 1.1, I will first update the code with ffa 1.0. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年7月3日(星期一) 14:30 收件人：Jens Wiklander <jens.wiklander(a)linaro.org> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：core: fix fragmented memory retrieve Hi, Jens, The previous fix was based on ffa_mem_transaction with ffa version 1.0, now optee and Hafnium have updated ffa_mem_transaction to ffa 1.1. But optee-driver in linaro-swg/linux seems to be using ffa version 1.0, which causes incorrect data reading when the driver is doing mem_share to Hafnium. I need to debug my previous code. When will optee-driver synchronize this version change? Regards, Yuye. ------------------------------------------------------------------ 发件人：Jens Wiklander <jens.wiklander(a)linaro.org> 发送时间：2023年6月28日(星期三) 17:54 收件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org> 主　题：Re: core: fix fragmented memory retrieve Hi Yuye, On Wed, Jun 28, 2023 at 11:50 AM 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> wrote: > > > > > Hi, Jens, > > Sorry for forgetting to revise the PR in time, because my github email changed so I haven't received any comments. > Could you help me reopen the PR since I don't have the right? I will re-fix the problem as requested. > Thanks. > https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > I've reopened it. Cheers, Jens

2 years, 11 months

1
0
0 0

Preparing for OP-TEE 3.22.0

by Joakim Bech

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE v3.22.0 is scheduled to be released at 2023-07-07 (*). 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/6125. 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 Regards, Joakim Bech (*) We moved this from July 14th to July 7th due to vacation and holiday schedules.

2 years, 11 months

1
1
0 0

optee_benchmark found optee_os function vm_set_ctx() spent much time

by haiyuan.ghy＠alibaba-inc.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 years, 11 months

3
8
0 0

core: fix fragmented memory retrieve

by 梅建强(禹夜)

Hi, Jens, Sorry for forgetting to revise the PR in time, because my github email changed so I haven't received any comments. Could you help me reopen the PR since I don't have the right? I will re-fix the problem as requested. Thanks. https://github.com/OP-TEE/optee_os/pull/5966 <https://github.com/OP-TEE/optee_os/pull/5966 > Regards, Yuye.

2 years, 12 months

2
1
0 0

[RFC PATCH 1/1] tests/avocado: Introduce avocado tests for aarch64 S-EL2 booting

by shiju.jose＠huawei.com

From: Shiju Jose <shiju.jose(a)huawei.com> Add avocado tests for aarch64 S-EL2, include booting and run xtest on linux terminal. The prebuilt S-EL2 images are corresponding to the https://github.com/jenswi-linaro/manifest.git \ -m qemu_v8.xml -b qemu_sel2 How to run ========== "make check-avocado" in qemu/build or with QEMU_CI=1 and QEMU_CI_AVOCADO_TESTING=1 "amd64-fedora-container", "build-cfi-aarch64" and "avocado-cfi-aarch64" on gitlab for qemu Question: Presently tested with the prebuilt images temporarily in /tests/data/sel2-boot-images/prebuilt-sel2-images.zip Can the prebuilt images for SEL2 available in the OP-TEE/TF-A/similar release? Note1: The pre-built S-EL2 images used are few months old as there are some issue found in xtest with the images build from the recent Linaro SEL2 code. Note2: On gitlab CI, there is an outstanding issue found in booting linux, after starting network OK. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> --- tests/avocado/machine_aarch64_virt.py | 63 ++++++++++++++++++ .../sel2-boot-images/prebuilt-sel2-images.zip | Bin 0 -> 23151996 bytes 2 files changed, 63 insertions(+) create mode 100644 tests/data/sel2-boot-images/prebuilt-sel2-images.zip diff --git a/tests/avocado/machine_aarch64_virt.py b/tests/avocado/machine_aarch64_virt.py index a90dc6ff4b..039673fd40 100644 --- a/tests/avocado/machine_aarch64_virt.py +++ b/tests/avocado/machine_aarch64_virt.py @@ -11,13 +11,16 @@ import time import os import logging +import shutil from avocado_qemu import QemuSystemTest from avocado_qemu import wait_for_console_pattern from avocado_qemu import exec_command from avocado_qemu import BUILD_DIR +from avocado_qemu import is_readable_executable_file from avocado.utils import process from avocado.utils.path import find_command +from avocado.utils import archive class Aarch64VirtMachine(QemuSystemTest): KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 ' @@ -144,3 +147,63 @@ def test_aarch64_virt_gicv2(self): :avocado: tags=cpu:max """ self.common_aarch64_virt("virt,gic-version=2") + + def copy_sel2_prebuilt_images(self): + """extract the prebuilt S-EL2 binaries to the test directory. """ + + relative_path = "./tests/data/sel2-boot-images/prebuilt-sel2-images.zip" + prebuilt_bin_path = os.path.join(BUILD_DIR, relative_path) + target_dir = os.path.join(BUILD_DIR) + + self.assertTrue(os.path.exists(prebuilt_bin_path)) + self.assertTrue(os.path.exists(target_dir)) + archive.extract(prebuilt_bin_path, target_dir) + + timeout = 1000 + def test_aarch64_sel2_boot(self): + """ + :avocado: tags=arch:aarch64 + :avocado: tags=machine:secure + :avocado: tags=machine:virt + :avocado: tags=cpu:max + """ + + self.copy_sel2_prebuilt_images() + self.vm.set_console() + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE + + 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 nokaslr') + + self.vm.add_args("-cpu", "max,sme=off,pauth-impdef=on") + self.vm.add_args("-machine", + "virt,secure=on," + "virtualization=on," + "mte=on," + "gic-version=3") + self.vm.add_args("-d", "unimp") + self.vm.add_args("-semihosting-config", "enable=on,target=native") + self.vm.add_args("-smp", "2", "-m", "1024") + self.vm.add_args('-bios', 'bl1.bin') + self.vm.add_args('-initrd', 'rootfs.cpio.gz') + self.vm.add_args('-kernel', 'Image') + self.vm.add_args('-machine', 'acpi=off') + self.vm.add_args('-append', kernel_command_line) + self.vm.add_args('-object', 'rng-random,filename=/dev/urandom,id=rng0') + self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000') + self.vm.launch() + self.wait_for_console_pattern('Welcome to Buildroot') + time.sleep(0.1) + exec_command(self, 'root') + time.sleep(0.1) + + def test_aarch64_sel2_xtest(self): + """ + :avocado: tags=arch:aarch64 + :avocado: tags=machine:secure + :avocado: tags=machine:virt + :avocado: tags=cpu:max + """ + self.test_aarch64_sel2_boot() + exec_command(self, 'xtest') + time.sleep(0.1) + self.wait_for_console_pattern('subtests of which 0 failed') + time.sleep(0.1) diff --git a/tests/data/sel2-boot-images/prebuilt-sel2-images.zip b/tests/data/sel2-boot-images/prebuilt-sel2-images.zip new file mode 100644 index 0000000000..13c5e1e4cc Binary files /dev/null and b/tests/data/sel2-boot-images/prebuilt-sel2-images.zip differ -- 2.25.1

2 years, 12 months

1
0
0 0

Linaro OP-TEE Contribution, LOC, monthly meeting June 27

by Jens Wiklander

Hi, On Tuesday, June 27 it's time for another LOC monthly meeting. For time and connection details see the calendar at https://www.trustedfirmware.org/meetings/ I'd like to discuss how MbedTLS is used in OP-TEE. While trying to update to MbedTLS 3.4 on the 4.x WIP branch [1] we have run into yet another issue with the CRT parameters used in the RSA implementation. See [2] for more details on the CRT problem. [1] https://github.com/jenswi-linaro/optee_os/tree/wip_4_0_0 [2] https://github.com/jenswi-linaro/optee_os/pull/9 any other topics? Thanks, Jens

3 years

1
0
0 0

PKCS11 TA: MR https://github.com/OP-TEE/optee_os/pull/5166

by dourlent cédric

Hi, I contact you about the merge request https://github.com/OP-TEE/optee_os/pull/5166 that is mandatory to be able to use ECC private key imported in PKCS11 TA and not generate by the TA. Currently the status is Attribute on generated ECC private key are - EC_PARAMS - VALUE - EC_POINT => This object can be use for crypto operation Attribute on imported ECC private key are - EC_PARAMS - VALUE => PKCS11 TA can not use it because TA expect EC_POINTS attributes on ECC Private key. Could you accept the merge request and have a coherence between generated and imported object even if for the moment it's doesn't respect PKCS11 standard ? Two options for the next step. - check with PKCS11 editors to upgrade the spec and have a same behavior between RSA Private object and ECC Private object. - rework the code of the TA for ECC to link Private and public object but that mean that ECC Private and Public object must be present in the same slot to be able to perform crypto operation. Best regards, Cédric Dourlent,

3 years

3
2
0 0

[GIT PULL] Use kmemdup() in OP-TEE driver for v6.5

by Jens Wiklander

Hello arm-soc maintainers, Please pull this small patch to the OP-TEE driver that replaces kmalloc() + memcpy() with kmemdup() at one place. Thanks, Jens The following changes since commit f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6: Linux 6.4-rc2 (2023-05-14 12:51:40 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/optee-use-kmemdup-for-6.5 for you to fetch changes up to 6a8b7e80105416cc7324fda295608ea2d3f98862: tee: optee: Use kmemdup() to replace kmalloc + memcpy (2023-06-15 08:49:55 +0200) ---------------------------------------------------------------- Use kmemdup() in OP-TEE driver ---------------------------------------------------------------- Jiapeng Chong (1): tee: optee: Use kmemdup() to replace kmalloc + memcpy drivers/tee/optee/smc_abi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

3 years

1
0
0 0

[PATCH v2] tee: optee: Use kmemdup() to replace kmalloc + memcpy

by Jiapeng Chong

Use kmemdup rather than duplicating its implementation. ./drivers/tee/optee/smc_abi.c:1542:12-19: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5480 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- Changes in v2: -Add one commit message. drivers/tee/optee/smc_abi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index 3861ae06d902..d5b28fd35d66 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1541,12 +1541,11 @@ static int optee_load_fw(struct platform_device *pdev, * This uses the GFP_DMA flag to ensure we are allocated memory in the * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. */ - data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + data_buf = kmemdup(fw->data, fw->size, GFP_KERNEL | GFP_DMA); if (!data_buf) { rc = -ENOMEM; goto fw_err; } - memcpy(data_buf, fw->data, fw->size); data_pa = virt_to_phys(data_buf); reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); reg_pair_from_64(&data_size_high, &data_size_low, data_size); -- 2.20.1.7.g153144c

3 years

3
2
0 0

reference keymint & gatekeeper TAs

by Nagendra Modadugu

I'm writing to get further information regarding the support roadmap for OP-TEE based TA's - specifically keymint and gatekeeper. The implementations I could find are here: https://github.com/linaro-swg/kmgk, and was wondering whether these are supported? Please respond off list if you find that would be more appropriate for discussion. thanks.

3 years

2
1
0 0

[PATCH v2 0/4] rpmb subsystem, uapi and virtio-rpmb driver

by Shyam Saini

Hi Alex, [ Resending, Sorry for the noise ] Are you still working on it or planning to resubmit it ? [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. The ftpm has dependency on tee-supplicant which comes once the user space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space tee supplicant. To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. Please let me know what's your plan on this. [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html Best Regards, Shyam

3 years

5
7
0 0

Re: FOLL_LONGTERM vs FOLL_EPHEMERAL Re: [PATCH] tee: add FOLL_LONGTERM for CMA case when alloc shm

by Sumit Garg

On Tue, 13 Jun 2023 at 11:00, Xiaoming Ding (丁晓明) <Xiaoming.Ding(a)mediatek.com> wrote: > > So do we have a conclution about this patch? or need more time to > study the possible risks Please avoid top posting. As already discussed here [1], RLIMIT_MEMLOCK checks have to be implemented if we switch to FOLL_LONGTERM. [1] https://lists.trustedfirmware.org/archives/list/op-tee@lists.trustedfirmwar… -Sumit > > On Tue, 2023-05-23 at 08:25 +0100, Lorenzo Stoakes wrote: > > External email : Please do not click links or open attachments until > > you have verified the sender or the content. > > > > > > On Mon, May 22, 2023 at 06:54:29PM -0700, John Hubbard wrote: > > > On 5/18/23 06:56, David Hildenbrand wrote: > > > > On 18.05.23 08:08, Sumit Garg wrote: > > > > > On Thu, 18 May 2023 at 09:51, Christoph Hellwig < > > > > > hch(a)infradead.org> wrote: > > > > > > > > > > > > On Wed, May 17, 2023 at 08:23:33PM +0200, David Hildenbrand > > > > > > wrote: > > > > > > > In general: if user space controls it -> possibly forever > > > > > > > -> long-term. Even > > > > > > > if in most cases it's a short delay: there is no trusting > > > > > > > on user space. > > > > > > > > > > > > > > For example, iouring fixed buffers keep pages pinned until > > > > > > > user space > > > > > > > decides to unregistered the buffers -> long-term. > > > > > > > > > > > > > > Short-term is, for example, something like O_DIRECT where > > > > > > > we pin -> DMA -> > > > > > > > unpin in essentially one operation. > > > > > > > > > > > > Btw, one thing that's been on my mind is that I think we got > > > > > > the > > > > > > polarity on FOLL_LONGTERM wrong. Instead of opting into the > > > > > > long term > > > > > > behavior it really should be the default, with a > > > > > > FOLL_EPHEMERAL flag > > > > > > to opt out of it. And every users of this flag is required > > > > > > to have > > > > > > a comment explaining the life time rules for the pin.. > > > > I couldn't agree more, based on my recent forays into GUP the > > interface > > continues to strike me as odd:- > > > > - FOLL_GET is a wing and a prayer that nothing that > > [folio|page]_maybe_dma_pinned() prevents happens in the brief > > period the > > page is pinned/manipulated. So agree completely with David's > > concept of > > unexporting that and perhaps carefully considering our use of > > it. Obviously the comments around functions like gup_remote() make > > clear > > that 'this page not be what you think it is' but I wonder whether > > many > > callers of GUP _truly_ take that on board. > > > > - FOLL_LONGTERM is entirely optional for PUP and you can just go > > ahead and > > fragment page blocks to your heart's content. Of course this would > > be an > > abuse, but abuses happen. > > > > - With the recent change to PUP/FOLL_LONGTERM disallowing dirty > > tracked > > file-backed mappings we're now really relying on this flag > > indicating a > > _long term_ pin semantically. By defaulting to this being switched > > on, we > > avoid cases of callers who might end up treating the won't > > reclaim/etc. aspect of PUP as all they care about while ignoring > > the > > MIGRATE_MOVABLE aspect. > > > > > > > > I see maybe 10 or 20 call sites today. So it is definitely feasible > > > to add > > > documentation at each, explaining the why it wants a long term pin. > > > > > > > Yeah, my efforts at e.g. dropping vmas has been eye-opening in > > actually > > quite how often a refactoring like this often ends up being more > > straightforward than you might imagine. > > > > > > > > > > > > It does look like a better approach to me given the very nature > > > > > of > > > > > user space pages. > > > > > > > > Yeah, there is a lot of historical baggage. For example, FOLL_GET > > > > should be inaccessible to kernel modules completely at one point, > > > > to be only used by selected core-mm pieces. > > > > > > Yes. When I first mass-converted call sites from gup to pup, I just > > > preserved FOLL_GET behavior in order to keep from changing too much > > > at > > > once. But I agree that that it would be nice to make FOLL_GET an > > > mm internal-only flag like FOLL_PIN. > > > > Very glad you did that work! And totally understandable as to you > > being > > conservative with that, but I think we're at a point where there's > > more > > acceptance of incremental improvements to GUP as a whole. > > > > I have another patch series saved up for _yet more_ changes on this. > > But > > mindful of churn I am trying to space them out... until Jason nudges > > me of > > course :) > > > > > > > > > > > > > Maybe we should even disallow passing in FOLL_LONGTERM as a flag > > > > and only provide functions like pin_user_pages() vs. > > > > pin_user_pages_longterm(). Then, discussions about conditional > > > > flag-setting are no more :) > > > > > > > > ... or even use pin_user_pages_shortterm() vs. pin_user_pages() > > > > ... to make the default be longterm. > > > > > > > > > > Yes, it is true that having most gup flags be internal to mm does > > > tend > > > to avoid some bugs. But it's also a lot of churn. I'm still on the > > > fence > > > as to whether it's really a good move to do this for FOLL_LONGTERM > > > or > > > not. But it's really easy to push me off of fences. :) > > > > *nudge* ;) > > > > > > > > thanks, > > > -- > > > John Hubbard > > > NVIDIA > > > > > > > Looking at non-fast, non-FOLL_LONGTERM PUP callers (forgive me if I > > missed any):- > > > > - pin_user_pages_remote() in process_vm_rw_single_vec() for the > > process_vm_access functionality. > > > > - pin_user_pages_remote() in user_event_enabler_write() in > > kernel/trace/trace_events_user.c. > > > > - pin_user_pages_unlocked() in ivtv_udma_setup() in > > drivers/media/pci/ivtv/ivtv-udma.c and ivtv_yuv_prep_user_dma() in > > ivtv-yuv.c. > > > > And none that actually directly invoke PUP without FOLL_LOGNTERM... > > That > > suggests that we could simply disallow non-FOLL_LONGTERM non-fast PUP > > calls > > altogether and move to pin_user_pages_longterm() [I'm happy to write > > a > > patch series doing this]. > > > > The ivtv callers look like they really actually want FOLL_LONGTERM > > unless > > I'm missing something so we should probably change that too? > > > > I haven't surveyed the fast versions, but I think defaulting to > > FOLL_LONGTERM on them also makes sense. >

3 years

1
0
0 0

[PATCH] tee: optee: Use kmemdup() to replace kmalloc + memcpy

by Jiapeng Chong

./drivers/tee/optee/smc_abi.c:1542:12-19: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5480 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/tee/optee/smc_abi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index 3861ae06d902..d5b28fd35d66 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1541,12 +1541,11 @@ static int optee_load_fw(struct platform_device *pdev, * This uses the GFP_DMA flag to ensure we are allocated memory in the * 32-bit space since TF-A cannot map memory beyond the 32-bit boundary. */ - data_buf = kmalloc(fw->size, GFP_KERNEL | GFP_DMA); + data_buf = kmemdup(fw->data, fw->size, GFP_KERNEL | GFP_DMA); if (!data_buf) { rc = -ENOMEM; goto fw_err; } - memcpy(data_buf, fw->data, fw->size); data_pa = virt_to_phys(data_buf); reg_pair_from_64(&data_pa_high, &data_pa_low, data_pa); reg_pair_from_64(&data_size_high, &data_size_low, data_size); -- 2.20.1.7.g153144c

3 years

2
1
0 0

[PATCH v5 0/3] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v4 -> v5 - rebase to efi-next based on v6.4-rc1 - set generic_ops.query_variable_info, it works as expected as follows. $ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 16K 1.3K 15K 8% /sys/firmware/efi/efivars v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Masahisa Kojima (3): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 12 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 638 +++++++++++++++++++ include/linux/efi.h | 4 + 6 files changed, 906 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c -- 2.30.2

3 years

6
33
0 0

[PATCH v5 1/2] dt-bindings: arm: optee: add interrupt controller properties

by Etienne Carriere

Adds an optional interrupt controller property to optee firmware node in the DT bindings. Optee driver may embeds an irqchip exposing OP-TEE interrupt events notified by the TEE world. Optee registers up to 1 interrupt controller and identifies each line with a line number from 0 to UINT16_MAX. The identifiers and meaning of the interrupt line number are specific to the platform and shall be found in the OP-TEE platform documentation. In the example shown in optee DT binding documentation, the platform SCMI device controlled by Linux scmi driver uses optee interrupt irq 5 as signal to trigger processing of an asynchronous incoming SCMI message in the scope of a CPU DVFS control. A platform can have several SCMI channels driven this way. Optee irqs also permit small embedded devices to share e.g. a gpio expander, a group of wakeup sources, etc... between OP-TEE world (for sensitive services) and Linux world (for non-sensitive services). The physical controller is driven from the TEE which exposes some controls to Linux kernel. Cc: Jens Wiklander <jens.wiklander(a)linaro.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt(a)linaro.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Sumit Garg <sumit.garg(a)linaro.org> Co-developed-by: Pascal Paillet <p.paillet(a)foss.st.com> Signed-off-by: Pascal Paillet <p.paillet(a)foss.st.com> Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> --- Changes since v4: - Removed empty line between Cc: tags and S-o-b tags. No changes since v3 Changes since v2: - Added a sentence on optee irq line number values and meaning, in DT binding doc and commit message. - Updated example in DT binding doc from comment, fixed misplaced interrupt-parent property and removed gic and sram shm nodes. Changes since v1: - Added a description to #interrupt-cells property. - Changed of example. Linux wakeup event was subject to discussion and i don't know much about input events in Linux. So move to SCMI. In the example, an SCMI server in OP-TEE world raises optee irq 5 so that Linux scmi optee channel &scmi_cpu_dvfs pushed in the incoming SCMI message in the scmi device for liekly later processing in threaded context. The example includes all parties: optee, scmi, sram, gic. - Obviously rephrased the commit message. --- .../arm/firmware/linaro,optee-tz.yaml | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index 5d033570b57b..9d9a797a6b2f 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -41,6 +41,16 @@ properties: HVC #0, register assignments register assignments are specified in drivers/tee/optee/optee_smc.h + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: | + OP-TEE exposes irq for irp chip controllers from OP-TEE world. Each + irq is assigned a single line number identifier used as first argument. + Line number identifiers and their meaning shall be found in the OP-TEE + firmware platform documentation. + required: - compatible - method @@ -65,3 +75,31 @@ examples: method = "hvc"; }; }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + firmware { + optee: optee { + compatible = "linaro,optee-tz"; + method = "smc"; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>; + interrupt-controller; + #interrupt-cells = <1>; + }; + + scmi { + compatible = "linaro,scmi-optee"; + linaro,optee-channel-id = <0>; + shmem = <&scmi_shm_tx>, <&scmi_shm_rx>; + interrupts-extended = <&optee 5>; + interrupt-names = "a2p"; + #address-cells = <1>; + #size-cells = <0>; + + scmi_cpu_dvfs: protocol@13 { + reg = <0x13>; + #clock-cells = <1>; + }; + }; + }; -- 2.25.1

3 years

3
4
0 0

[PATCH] tee: optee: Fix supplicant based device enumeration

by Sumit Garg

Currently supplicant dependent optee device enumeration only registers devices whenever tee-supplicant is invoked for the first time. But it forgets to remove devices when tee-supplicant daemon stops running and closes its context gracefully. This leads to following splats for fTPM driver during reboot/shutdown: [ 73.466791] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024 [ 73.474497] ------------[ cut here ]------------ [ 73.479119] WARNING: CPU: 1 PID: 1 at drivers/char/tpm/tpm_ftpm_tee.c:135 ftpm_tee_tpm_op_send+0x200/0x25c <snip> [ 73.539952] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 73.545946] pc : ftpm_tee_tpm_op_send+0x200/0x25c [ 73.550640] lr : ftpm_tee_tpm_op_send+0x200/0x25c [ 73.555331] sp : ffff80001129baa0 [ 73.558635] x29: ffff80001129baa0 x28: ffff00000646f000 [ 73.563938] x27: ffff8000110f7000 x26: 0000000000000016 [ 73.569241] x25: 0000000000000145 x24: ffff000005395000 [ 73.574544] x23: ffff0000065a7280 x22: ffff00000646f000 [ 73.579847] x21: ffff000006422080 x20: 000000000000000c [ 73.585149] x19: 0000000000000000 x18: 0000000000000000 [ 73.590450] x17: 0000000000000000 x16: 0000000000000000 [ 73.595753] x15: 0000000000000030 x14: ffffffffffffffff [ 73.601055] x13: ffff80001110e838 x12: 00000000000006d2 [ 73.606357] x11: 0000000000000246 x10: ffff800011166838 [ 73.611659] x9 : 00000000fffff000 x8 : ffff80001110e838 [ 73.616962] x7 : ffff800011166838 x6 : 0000000000000000 [ 73.622263] x5 : 0000000000000000 x4 : 0000000000000000 [ 73.627565] x3 : 0000000000000000 x2 : 0000000000000000 [ 73.632867] x1 : 0000000000000000 x0 : ffff0000000e8000 [ 73.638170] Call trace: [ 73.640610] ftpm_tee_tpm_op_send+0x200/0x25c [ 73.644960] tpm_transmit+0xc8/0x33c [ 73.648528] tpm_transmit_cmd+0x30/0xc0 [ 73.652353] tpm2_shutdown+0xa4/0x100 [ 73.656007] tpm_class_shutdown+0x60/0x90 [ 73.660009] device_shutdown+0x138/0x330 [ 73.663926] __do_sys_reboot+0x218/0x2a0 [ 73.667839] __arm64_sys_reboot+0x24/0x30 [ 73.671842] el0_svc_common.constprop.0+0x78/0x1c4 [ 73.676622] do_el0_svc+0x24/0x8c [ 73.679932] el0_svc+0x14/0x20 [ 73.682978] el0_sync_handler+0xb0/0xb4 [ 73.686806] el0_sync+0x180/0x1c0 Fix this properly by removing supplicant dependent devices when the supplicant closes gracefully. While at it use the global system workqueue for OP-TEE bus scanning work rather than our own custom one. Reported-by: Jan Kiszka <jan.kiszka(a)siemens.com> Link: https://github.com/OP-TEE/optee_os/issues/6094 Fixes: 5f178bb71e3a ("optee: enable support for multi-stage bus enumeration") Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- drivers/tee/optee/core.c | 26 +++++++++++--------------- drivers/tee/optee/device.c | 27 ++++++++++++++++++++++++--- drivers/tee/optee/optee_private.h | 7 ++----- 3 files changed, 37 insertions(+), 23 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index d01ca47f7bde..e0f2c9cb0073 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -15,7 +15,6 @@ #include <linux/string.h> #include <linux/tee_drv.h> #include <linux/types.h> -#include <linux/workqueue.h> #include "optee_private.h" int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm, @@ -84,6 +83,11 @@ static void optee_bus_scan(struct work_struct *work) WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP)); } +static void optee_bus_remove(struct work_struct *work) +{ + optee_unregister_supp_devices(); +} + int optee_open(struct tee_context *ctx, bool cap_memref_null) { struct optee_context_data *ctxdata; @@ -108,16 +112,8 @@ int optee_open(struct tee_context *ctx, bool cap_memref_null) return -EBUSY; } - if (!optee->scan_bus_done) { - INIT_WORK(&optee->scan_bus_work, optee_bus_scan); - optee->scan_bus_wq = create_workqueue("optee_bus_scan"); - if (!optee->scan_bus_wq) { - kfree(ctxdata); - return -ECHILD; - } - queue_work(optee->scan_bus_wq, &optee->scan_bus_work); - optee->scan_bus_done = true; - } + INIT_WORK(&optee->scan_bus_work, optee_bus_scan); + schedule_work(&optee->scan_bus_work); } mutex_init(&ctxdata->mutex); INIT_LIST_HEAD(&ctxdata->sess_list); @@ -159,10 +155,10 @@ void optee_release_supp(struct tee_context *ctx) struct optee *optee = tee_get_drvdata(ctx->teedev); optee_release_helper(ctx, optee_close_session_helper); - if (optee->scan_bus_wq) { - destroy_workqueue(optee->scan_bus_wq); - optee->scan_bus_wq = NULL; - } + + INIT_WORK(&optee->scan_bus_work, optee_bus_remove); + schedule_work(&optee->scan_bus_work); + optee_supp_release(&optee->supp); } diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c index 64f0e047c23d..88e1c3feb15d 100644 --- a/drivers/tee/optee/device.c +++ b/drivers/tee/optee/device.c @@ -60,9 +60,10 @@ static void optee_release_device(struct device *dev) kfree(optee_device); } -static int optee_register_device(const uuid_t *device_uuid) +static int optee_register_device(const uuid_t *device_uuid, u32 func) { struct tee_client_device *optee_device = NULL; + const char *dev_name_fmt = NULL; int rc; optee_device = kzalloc(sizeof(*optee_device), GFP_KERNEL); @@ -71,7 +72,13 @@ static int optee_register_device(const uuid_t *device_uuid) optee_device->dev.bus = &tee_bus_type; optee_device->dev.release = optee_release_device; - if (dev_set_name(&optee_device->dev, "optee-ta-%pUb", device_uuid)) { + + if (func == PTA_CMD_GET_DEVICES_SUPP) + dev_name_fmt = "optee-ta-supp-%pUb"; + else + dev_name_fmt = "optee-ta-%pUb"; + + if (dev_set_name(&optee_device->dev, dev_name_fmt, device_uuid)) { kfree(optee_device); return -ENOMEM; } @@ -142,7 +149,7 @@ static int __optee_enumerate_devices(u32 func) num_devices = shm_size / sizeof(uuid_t); for (idx = 0; idx < num_devices; idx++) { - rc = optee_register_device(&device_uuid[idx]); + rc = optee_register_device(&device_uuid[idx], func); if (rc) goto out_shm; } @@ -175,3 +182,17 @@ void optee_unregister_devices(void) bus_for_each_dev(&tee_bus_type, NULL, NULL, __optee_unregister_device); } + +static int __optee_unregister_supp_device(struct device *dev, void *data) +{ + if (!strncmp(dev_name(dev), "optee-ta-supp", strlen("optee-ta-supp"))) + device_unregister(dev); + + return 0; +} + +void optee_unregister_supp_devices(void) +{ + bus_for_each_dev(&tee_bus_type, NULL, NULL, + __optee_unregister_supp_device); +} diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index 6dcecb83c893..cb5eae6f797d 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -192,9 +192,7 @@ struct optee_ops { * @supp: supplicant synchronization struct for RPC to supplicant * @pool: shared memory pool * @rpc_param_count: If > 0 number of RPC parameters to make room for - * @scan_bus_done flag if device registation was already done. - * @scan_bus_wq workqueue to scan optee bus and register optee drivers - * @scan_bus_work workq to scan optee bus and register optee drivers + * @scan_bus_work work to scan optee bus and register optee drivers */ struct optee { struct tee_device *supp_teedev; @@ -211,8 +209,6 @@ struct optee { struct optee_supp supp; struct tee_shm_pool *pool; unsigned int rpc_param_count; - bool scan_bus_done; - struct workqueue_struct *scan_bus_wq; struct work_struct scan_bus_work; }; @@ -280,6 +276,7 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session); #define PTA_CMD_GET_DEVICES_SUPP 0x1 int optee_enumerate_devices(u32 func); void optee_unregister_devices(void); +void optee_unregister_supp_devices(void); int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm, size_t size, size_t align, -- 2.34.1

3 years

2
1
0 0

[GIT PULL] AMDTEE fix for v6.5

by Jens Wiklander

Hello arm-soc maintainers, Please pull this AMDTEE driver fix to add a return origin field to the struct tee_cmd_load_ta used when loading a Trusted Application into the AMDTEE. This change is backward compatible. Note that this isn't a usual Arm driver update. This targets AMD instead, but is part of the TEE subsystem. Thanks, Jens The following changes since commit f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6: Linux 6.4-rc2 (2023-05-14 12:51:40 -0700) are available in the Git repository at: https://git.linaro.org/people/jens.wiklander/linux-tee.git tags/amdtee-fix-for-v6.5 for you to fetch changes up to 436eeae0411acdfc54521ddea80ee76d4ae8a7ea: tee: amdtee: Add return_origin to 'struct tee_cmd_load_ta' (2023-05-15 08:29:52 +0200) ---------------------------------------------------------------- AMDTEE add return origin to load TA command ---------------------------------------------------------------- Rijo Thomas (1): tee: amdtee: Add return_origin to 'struct tee_cmd_load_ta' drivers/tee/amdtee/amdtee_if.h | 10 ++++++---- drivers/tee/amdtee/call.c | 30 +++++++++++++++++------------- 2 files changed, 23 insertions(+), 17 deletions(-)

3 years

2
3
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, Olivier, That makes it clearer to me. Thanks a lot. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年5月30日(星期二) 21:07 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：Re: optee_benchmark pmccfiltr_el0 Hi Yuye, In general the consensus is that PMU cycle and event counting in EL3 & secure world has to be disabled. I gather this is to avoid probing crypto algorithms timings, or leverage cache-based timing side channels (e.g. spectre). See Arm ARM D11.5.3 Prohibiting event and cycle counting Cycle and event counting is disabled by: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… <https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/include/ar… > See also https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… <https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardeni… > Note there are various knobs depending on implemented architecture extensions FEAT_PMUv3 / FEAT_PMUv3pX / FEAT_Debugv8p2 You could try to permit cycle counting in the secure world for the sake of a one shot experiment, but note that this has never been tried, and this should probably not be productized as things stand. Regards, Olivier. From: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> Sent: 30 May 2023 10:38 To: Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: optee_benchmark pmccfiltr_el0 Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

3 years

1
0
0 0

[RFC PATCH 0/4] introduction of a remoteproc tee to load signed firmware images

by Arnaud Pouliquen

This RFC proposes an implementation of a remoteproc tee driver to communicate with a TEE trusted application in charge of authenticating and loading remoteproc firmware image in an Arm secure context. The services implemented are the same as those offered by the Linux remoteproc framework: - load of a signed firmware - start/stop of a coprocessor - get the resource table The OP-TEE code in charge of providing the service in a trusted application is proposed for upstream here: https://github.com/OP-TEE/optee_os/pull/6027 For more details on the implementation a presentation is available here: https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds Arnaud Pouliquen (4): tee: Re-enable vmalloc page support for shared memory remoteproc: Add TEE support dt-bindings: remoteproc: add compatibility for TEE support remoteproc: stm32: Add support of an OP-TEE TA to load the firmware .../bindings/remoteproc/st,stm32-rproc.yaml | 33 +- drivers/remoteproc/Kconfig | 9 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/stm32_rproc.c | 234 +++++++++-- drivers/remoteproc/tee_remoteproc.c | 397 ++++++++++++++++++ drivers/tee/tee_shm.c | 24 +- include/linux/tee_remoteproc.h | 101 +++++ 7 files changed, 753 insertions(+), 46 deletions(-) create mode 100644 drivers/remoteproc/tee_remoteproc.c create mode 100644 include/linux/tee_remoteproc.h -- 2.25.1

3 years

5
14
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, It is confirmed that the problem is related to the pmu register configuration and that pmccntr_el0 can be read at any exception level. Regards, Yuye. ------------------------------------------------------------------ 发件人：梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 发送时间：2023年5月26日(星期五) 16:59 收件人：Jens Wiklander <jens.wiklander(a)linaro.org>; Olivier Deprez <olivier.deprez(a)arm.com> 抄　送：op-tee <op-tee(a)lists.trustedfirmware.org>; hafnium <hafnium(a)lists.trustedfirmware.org>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：optee_benchmark pmccfiltr_el0 Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

3 years

2
1
0 0

[v2,0/4] rpmb subsystem, uapi and virtio-rpmb driver

by Shyam Saini

Hi Alex, Are you still working on it or planning to resubmit it ? [1] The current optee tee kernel driver implementation doesn't work when IMA is used with optee implemented ftpm. The ftpm has dependency on tee-supplicant which comes once the user-space is up and running and IMA attestation happens at boot time and it requires to extend ftpm PCRs. But IMA can't use PCRs if ftpm use secure emmc RPMB partition. As optee can only access RPMB via tee-supplicant(user space). So, there should be a fast path to allow optee os to access the RPMB parititon without waiting for user-space the tee supplicant. To achieve this fast path linux optee driver and mmc driver needs some work and finally it will need RPMB driver which you posted. Please let me know what's your plan on this. [1] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html Thanks, Shyam

3 years

1
0
0 0

[PATCH v9 3/4] tee: optee: support tracking system threads

by Sumit Garg

From: Etienne Carriere <etienne.carriere(a)linaro.org> Adds support in the OP-TEE driver to keep track of reserved system threads. The optee_cq_*() functions are updated to handle this if enabled. The SMC ABI part of the driver enables this tracking, but the FF-A ABI part does not. The logic allows atleast 1 OP-TEE thread can be reserved to TEE system sessions. For sake of simplicity, initialization of call queue management is factorized into new helper function optee_cq_init(). Co-developed-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> Co-developed-by: Sumit Garg <sumit.garg(a)linaro.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Disclaimer: Compile tested only Hi Etienne, Overall the idea we agreed upon was okay but the implementation looked complex to me. So I thought it would be harder to explain that via review and I decided myself to give a try at simplification. I would like you to test it if this still addresses the SCMI deadlock problem or not. Also, feel free to include this in your patchset if all goes fine wrt testing. -Sumit Changes since v8: - Simplified system threads tracking implementation. drivers/tee/optee/call.c | 72 +++++++++++++++++++++++++++++-- drivers/tee/optee/ffa_abi.c | 3 +- drivers/tee/optee/optee_private.h | 16 +++++++ drivers/tee/optee/smc_abi.c | 16 ++++++- 4 files changed, 99 insertions(+), 8 deletions(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 42e478ac6ce1..09e824e4dcaf 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -39,9 +39,27 @@ struct optee_shm_arg_entry { DECLARE_BITMAP(map, MAX_ARG_COUNT_PER_ENTRY); }; +void optee_cq_init(struct optee_call_queue *cq, int thread_count) +{ + mutex_init(&cq->mutex); + INIT_LIST_HEAD(&cq->waiters); + /* + * If cq->total_thread_count is 0 then we're not trying to keep + * track of how many free threads we have, instead we're relying on + * the secure world to tell us when we're out of thread and have to + * wait for another thread to become available. + */ + cq->total_thread_count = thread_count; + cq->free_thread_count = thread_count; +} + void optee_cq_wait_init(struct optee_call_queue *cq, struct optee_call_waiter *w, bool sys_thread) { + bool need_wait = false; + + memset(w, 0, sizeof(*w)); + /* * We're preparing to make a call to secure world. In case we can't * allocate a thread in secure world we'll end up waiting in @@ -53,15 +71,43 @@ void optee_cq_wait_init(struct optee_call_queue *cq, mutex_lock(&cq->mutex); /* - * We add ourselves to the queue, but we don't wait. This - * guarantees that we don't lose a completion if secure world - * returns busy and another thread just exited and try to complete - * someone. + * We add ourselves to a queue, but we don't wait. This guarantees + * that we don't lose a completion if secure world returns busy and + * another thread just exited and try to complete someone. */ init_completion(&w->c); list_add_tail(&w->list_node, &cq->waiters); + if (cq->total_thread_count && sys_thread) { + if (cq->free_thread_count > 0) + cq->free_thread_count--; + else + need_wait = true; + } else if (cq->total_thread_count) { + if (cq->free_thread_count > 1) + cq->free_thread_count--; + else + need_wait = true; + } + mutex_unlock(&cq->mutex); + + while (need_wait) { + optee_cq_wait_for_completion(cq, w); + mutex_lock(&cq->mutex); + if (sys_thread) { + if (cq->free_thread_count > 0) { + cq->free_thread_count--; + need_wait = false; + } + } else { + if (cq->free_thread_count > 1) { + cq->free_thread_count--; + need_wait = false; + } + } + mutex_unlock(&cq->mutex); + } } void optee_cq_wait_for_completion(struct optee_call_queue *cq, @@ -104,6 +150,8 @@ void optee_cq_wait_final(struct optee_call_queue *cq, /* Get out of the list */ list_del(&w->list_node); + cq->free_thread_count++; + /* Wake up one eventual waiting task */ optee_cq_complete_one(cq); @@ -361,6 +409,22 @@ int optee_open_session(struct tee_context *ctx, return rc; } +int optee_system_session(struct tee_context *ctx, u32 session) +{ + struct optee_context_data *ctxdata = ctx->data; + struct optee_session *sess; + + mutex_lock(&ctxdata->mutex); + + sess = find_session(ctxdata, session); + if (sess && !sess->use_sys_thread) + sess->use_sys_thread = true; + + mutex_unlock(&ctxdata->mutex); + + return 0; +} + int optee_close_session_helper(struct tee_context *ctx, u32 session, bool system_thread) { diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 5fde9d4100e3..0c9055691343 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -852,8 +852,7 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev) if (rc) goto err_unreg_supp_teedev; mutex_init(&optee->ffa.mutex); - mutex_init(&optee->call_queue.mutex); - INIT_LIST_HEAD(&optee->call_queue.waiters); + optee_cq_init(&optee->call_queue, 0); optee_supp_init(&optee->supp); optee_shm_arg_cache_init(optee, arg_cache_flags); ffa_dev_set_drvdata(ffa_dev, optee); diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index b68273051454..6dcecb83c893 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -40,15 +40,29 @@ typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, struct arm_smccc_res *); +/* + * struct optee_call_waiter - TEE entry may need to wait for a free TEE thread + * @list_node Reference in waiters list + * @c Waiting completion reference + */ struct optee_call_waiter { struct list_head list_node; struct completion c; }; +/* + * struct optee_call_queue - OP-TEE call queue management + * @mutex Serializes access to this struct + * @waiters List of threads waiting to enter OP-TEE + * @total_thread_count Overall number of thread context in OP-TEE or 0 + * @free_thread_count Number of threads context free in OP-TEE + */ struct optee_call_queue { /* Serializes access to this struct */ struct mutex mutex; struct list_head waiters; + int total_thread_count; + int free_thread_count; }; struct optee_notif { @@ -254,6 +268,7 @@ int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params, int optee_open_session(struct tee_context *ctx, struct tee_ioctl_open_session_arg *arg, struct tee_param *param); +int optee_system_session(struct tee_context *ctx, u32 session); int optee_close_session_helper(struct tee_context *ctx, u32 session, bool system_thread); int optee_close_session(struct tee_context *ctx, u32 session); @@ -303,6 +318,7 @@ static inline void optee_to_msg_param_value(struct optee_msg_param *mp, mp->u.value.c = p->u.value.c; } +void optee_cq_init(struct optee_call_queue *cq, int thread_count); void optee_cq_wait_init(struct optee_call_queue *cq, struct optee_call_waiter *w, bool sys_thread); void optee_cq_wait_for_completion(struct optee_call_queue *cq, diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index e2763cdcf111..3314ffeb91c8 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -1209,6 +1209,7 @@ static const struct tee_driver_ops optee_clnt_ops = { .release = optee_release, .open_session = optee_open_session, .close_session = optee_close_session, + .system_session = optee_system_session, .invoke_func = optee_invoke_func, .cancel_req = optee_cancel_req, .shm_register = optee_shm_register, @@ -1356,6 +1357,16 @@ static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn, return true; } +static unsigned int optee_msg_get_thread_count(optee_invoke_fn *invoke_fn) +{ + struct arm_smccc_res res; + + invoke_fn(OPTEE_SMC_GET_THREAD_COUNT, 0, 0, 0, 0, 0, 0, 0, &res); + if (res.a0) + return 0; + return res.a1; +} + static struct tee_shm_pool * optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm) { @@ -1609,6 +1620,7 @@ static int optee_probe(struct platform_device *pdev) struct optee *optee = NULL; void *memremaped_shm = NULL; unsigned int rpc_param_count; + unsigned int thread_count; struct tee_device *teedev; struct tee_context *ctx; u32 max_notif_value; @@ -1636,6 +1648,7 @@ static int optee_probe(struct platform_device *pdev) return -EINVAL; } + thread_count = optee_msg_get_thread_count(invoke_fn); if (!optee_msg_exchange_capabilities(invoke_fn, &sec_caps, &max_notif_value, &rpc_param_count)) { @@ -1725,8 +1738,7 @@ static int optee_probe(struct platform_device *pdev) if (rc) goto err_unreg_supp_teedev; - mutex_init(&optee->call_queue.mutex); - INIT_LIST_HEAD(&optee->call_queue.waiters); + optee_cq_init(&optee->call_queue, thread_count); optee_supp_init(&optee->supp); optee->smc.memremaped_shm = memremaped_shm; optee->pool = pool; -- 2.34.1

3 years

4
10
0 0

optee_benchmark pmccfiltr_el0

by 梅建强(禹夜)

Hi, Jens, Olivier, In case of that optee runs at sel1 and hafnium runs at sel2, we want to test benchmark by executing the following command at optee_benchmark path: ./out/benchmark ../optee_examples/out/ca/optee_example_hello_world After entering into the benchmark pta, the bm_timestamp function attempts to read the pmccfiltr_el0 register. In cold boot, the following code will be executed during hafnium initialization: vm->arch.trapped_features |= HF_FEATURE_PERFMON; This will prevent the secondary vm from accessing the performance counter registers. We remove the code, the bm_timestamp function can read pmccfiltr_el0 without trapping into hafnium. But the value of pmccfiltr_el0 remains unchanged and cannot be counted. We tried to read the register in hafnium and found that there was no change either. In contrast, in the normal world, pmccfiltr_el0 counts normally. Is it related to the pmu register configuration or does sel1 not support the pmccfiltr_el0 count at present? Thanks for the support. Regards, Yuye.

3 years

1
0
0 0

[PATCH v4 0/3] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v3 -> v4: - replace the reference from EDK2 to PI Specification - remove EDK2 source code reference comments - prepare nonblocking variant of set_variable, it just returns EFI_UNSUPPORTED - remove redundant buffer size check - argument name change in mm_communicate - function interface changes in setup_mm_hdr to remove (void **) cast v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is referred just to output error message Masahisa Kojima (3): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 12 + drivers/firmware/efi/stmm/mm_communication.h | 236 +++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 637 +++++++++++++++++++ include/linux/efi.h | 4 + 6 files changed, 905 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c -- 2.30.2

3 years

4
7
0 0

[PATCH v3 0/3] introduce tee-based EFI Runtime Variable Service

by Masahisa Kojima

This series introduces the tee based EFI Runtime Variable Service. The eMMC device is typically owned by the non-secure world(linux in this case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with OP-TEE, StandaloneMM(as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with OP-TEE and StandaloneMM. Changelog: v2 -> v3: - add CONFIG_EFI dependency to TEE_STMM_EFI - add missing return code check for tee_client_invoke_func() - directly call efivars_register/unregister from tee_stmm_efi.c rfc v1 -> v2: - split patch into three patches, one for drivers/tee, one for include/linux/efi.h, and one for the driver/firmware/efi/stmm - context/session management into probe() and remove() same as other tee client driver - StMM variable driver is moved from driver/tee/optee to driver/firmware/efi - use "tee" prefix instead of "optee" in driver/firmware/efi/stmm/tee_stmm_efi.c, this file does not contain op-tee specific code, abstracted by tee layer and StMM variable driver will work on other tee implementation. - PTA_STMM_CMD_COMMUNICATE -> PTA_STMM_CMD_COMMUNICATE - implement query_variable_store() but currently not used - no use of TEEC_SUCCESS, it is defined in driver/tee/optee/optee_private.h. Other tee client drivers use 0 instead of using TEEC_SUCCESS - remove TEEC_ERROR_EXCESS_DATA status, it is refered just to output error message Masahisa Kojima (3): efi: expose efivar generic ops register function efi: Add EFI_ACCESS_DENIED status code efi: Add tee-based EFI variable driver drivers/firmware/efi/Kconfig | 15 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/efi.c | 12 + drivers/firmware/efi/stmm/mm_communication.h | 249 ++++++++ drivers/firmware/efi/stmm/tee_stmm_efi.c | 626 +++++++++++++++++++ include/linux/efi.h | 4 + 6 files changed, 907 insertions(+) create mode 100644 drivers/firmware/efi/stmm/mm_communication.h create mode 100644 drivers/firmware/efi/stmm/tee_stmm_efi.c -- 2.30.2

3 years, 1 month

2
5
0 0

[PATCH] tee: add FOLL_LONGTERM for CMA case when alloc shm

by Xiaoming Ding

FOLL_LONGTERM will avoid share memory alloc from CMA region, which may be used in secure playback case. if part of CMA region taken by share memory for long term usage, CMA will failed to get whole buffer back. Signed-off-by: Xiaoming Ding <xiaoming.ding(a)mediatek.com> --- drivers/tee/tee_shm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 673cf0359494..ddd3947e2229 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -223,6 +223,7 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, size_t num_pages; void *ret; int rc; + u32 page_flag = FOLL_WRITE; if (!tee_device_get(teedev)) return ERR_PTR(-EINVAL); @@ -255,9 +256,11 @@ register_shm_helper(struct tee_context *ctx, unsigned long addr, ret = ERR_PTR(-ENOMEM); goto err_free_shm; } - +#if IS_ENABLED(CONFIG_CMA) + page_flag |= FOLL_LONGTERM; +#endif if (flags & TEE_SHM_USER_MAPPED) - rc = pin_user_pages_fast(start, num_pages, FOLL_WRITE, + rc = pin_user_pages_fast(start, num_pages, page_flag, shm->pages); else rc = shm_get_kernel_pages(start, num_pages, shm->pages); -- 2.18.0

3 years, 1 month

6
12
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE