- OP-TEE - lists.trustedfirmware.org

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

3 years

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

3 years

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

3 years

9
20
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE