Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
2903 discussions

Re: [PATCH v4 1/6] tee: add restricted memory allocation

by Jens Wiklander

On Wed, Jan 8, 2025 at 5:54 PM Simona Vetter <simona.vetter(a)ffwll.ch> wrote: > > On Tue, Dec 17, 2024 at 11:07:37AM +0100, Jens Wiklander wrote: > > Add restricted memory allocation to the TEE subsystem. > > > > Restricted memory refers to memory buffers behind a hardware enforced > > firewall. It is not accessible to the kernel during normal circumstances > > but rather only accessible to certain hardware IPs or CPUs executing in > > higher privileged mode than the kernel itself. This interface allows to > > allocate and manage such restricted memory buffers via interaction with > > a TEE implementation. > > > > A new ioctl TEE_IOC_RSTMEM_ALLOC is added to allocate these restricted > > memory buffers. > > > > The restricted memory is allocated for a specific use-case, like Secure > > Video Playback, Trusted UI, or Secure Video Recording where certain > > hardware devices can access the memory. > > > > More use-cases can be added in userspace ABI, but it's up to the backend > > drivers to provide the implementation. > > > > Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> > > --- > > drivers/tee/Makefile | 1 + > > drivers/tee/tee_core.c | 38 ++++++- > > drivers/tee/tee_private.h | 2 + > > drivers/tee/tee_rstmem.c | 201 +++++++++++++++++++++++++++++++++++++ > > drivers/tee/tee_shm.c | 2 + > > drivers/tee/tee_shm_pool.c | 69 ++++++++++++- > > include/linux/tee_core.h | 15 +++ > > include/linux/tee_drv.h | 2 + > > include/uapi/linux/tee.h | 44 +++++++- > > 9 files changed, 370 insertions(+), 4 deletions(-) > > create mode 100644 drivers/tee/tee_rstmem.c > > > > diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile > > index 5488cba30bd2..a4c6b55444b9 100644 > > --- a/drivers/tee/Makefile > > +++ b/drivers/tee/Makefile > > @@ -3,6 +3,7 @@ obj-$(CONFIG_TEE) += tee.o > > tee-objs += tee_core.o > > tee-objs += tee_shm.o > > tee-objs += tee_shm_pool.o > > +tee-objs += tee_rstmem.o > > obj-$(CONFIG_OPTEE) += optee/ > > obj-$(CONFIG_AMDTEE) += amdtee/ > > obj-$(CONFIG_ARM_TSTEE) += tstee/ > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > > index d113679b1e2d..f4a45b77753b 100644 > > --- a/drivers/tee/tee_core.c > > +++ b/drivers/tee/tee_core.c > > @@ -1,12 +1,13 @@ > > // SPDX-License-Identifier: GPL-2.0-only > > /* > > - * Copyright (c) 2015-2016, Linaro Limited > > + * Copyright (c) 2015-2022, 2024, Linaro Limited > > */ > > > > #define pr_fmt(fmt) "%s: " fmt, __func__ > > > > #include <linux/cdev.h> > > #include <linux/cred.h> > > +#include <linux/dma-buf.h> > > #include <linux/fs.h> > > #include <linux/idr.h> > > #include <linux/module.h> > > @@ -815,6 +816,38 @@ static int tee_ioctl_supp_send(struct tee_context *ctx, > > return rc; > > } > > > > +static int > > +tee_ioctl_rstmem_alloc(struct tee_context *ctx, > > + struct tee_ioctl_rstmem_alloc_data __user *udata) > > +{ > > + struct tee_ioctl_rstmem_alloc_data data; > > + struct dma_buf *dmabuf; > > + int id; > > + int fd; > > + > > + if (copy_from_user(&data, udata, sizeof(data))) > > + return -EFAULT; > > + > > + if (data.use_case == TEE_IOC_UC_RESERVED) > > + return -EINVAL; > > + > > + dmabuf = tee_rstmem_alloc(ctx, data.flags, data.use_case, data.size, > > + &id); > > + if (IS_ERR(dmabuf)) > > + return PTR_ERR(dmabuf); > > + if (put_user(id, &udata->id)) { > > + fd = -EFAULT; > > + goto err; > > + } > > + fd = dma_buf_fd(dmabuf, O_CLOEXEC); > > + if (fd < 0) > > + goto err; > > + return fd; > > +err: > > + dma_buf_put(dmabuf); > > + return fd; > > +} > > + > > static long tee_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) > > { > > struct tee_context *ctx = filp->private_data; > > @@ -839,6 +872,8 @@ static long tee_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) > > return tee_ioctl_supp_recv(ctx, uarg); > > case TEE_IOC_SUPPL_SEND: > > return tee_ioctl_supp_send(ctx, uarg); > > + case TEE_IOC_RSTMEM_ALLOC: > > + return tee_ioctl_rstmem_alloc(ctx, uarg); > > default: > > return -EINVAL; > > } > > @@ -1286,3 +1321,4 @@ MODULE_AUTHOR("Linaro"); > > MODULE_DESCRIPTION("TEE Driver"); > > MODULE_VERSION("1.0"); > > MODULE_LICENSE("GPL v2"); > > +MODULE_IMPORT_NS("DMA_BUF"); > > diff --git a/drivers/tee/tee_private.h b/drivers/tee/tee_private.h > > index 9bc50605227c..bf97796909c0 100644 > > --- a/drivers/tee/tee_private.h > > +++ b/drivers/tee/tee_private.h > > @@ -23,5 +23,7 @@ void teedev_ctx_put(struct tee_context *ctx); > > struct tee_shm *tee_shm_alloc_user_buf(struct tee_context *ctx, size_t size); > > struct tee_shm *tee_shm_register_user_buf(struct tee_context *ctx, > > unsigned long addr, size_t length); > > +struct dma_buf *tee_rstmem_alloc(struct tee_context *ctx, u32 flags, > > + u32 use_case, size_t size, int *shm_id); > > > > #endif /*TEE_PRIVATE_H*/ > > diff --git a/drivers/tee/tee_rstmem.c b/drivers/tee/tee_rstmem.c > > new file mode 100644 > > index 000000000000..536bca2901e2 > > --- /dev/null > > +++ b/drivers/tee/tee_rstmem.c > > @@ -0,0 +1,201 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Copyright (c) 2024 Linaro Limited > > + */ > > +#include <linux/device.h> > > +#include <linux/dma-buf.h> > > +#include <linux/genalloc.h> > > +#include <linux/scatterlist.h> > > +#include <linux/slab.h> > > +#include <linux/tee_core.h> > > +#include "tee_private.h" > > + > > +struct tee_rstmem_attachment { > > + struct sg_table table; > > + struct device *dev; > > +}; > > + > > +static int rstmem_dma_attach(struct dma_buf *dmabuf, > > + struct dma_buf_attachment *attachment) > > +{ > > + struct tee_shm *shm = dmabuf->priv; > > + struct tee_rstmem_attachment *a; > > + int rc; > > + > > + a = kzalloc(sizeof(*a), GFP_KERNEL); > > + if (!a) > > + return -ENOMEM; > > + > > + if (shm->pages) { > > + rc = sg_alloc_table_from_pages(&a->table, shm->pages, > > + shm->num_pages, 0, > > + shm->num_pages * PAGE_SIZE, > > + GFP_KERNEL); > > + if (rc) > > + goto err; > > + } else { > > + rc = sg_alloc_table(&a->table, 1, GFP_KERNEL); > > + if (rc) > > + goto err; > > + sg_set_page(a->table.sgl, phys_to_page(shm->paddr), shm->size, > > + 0); > > + } > > + > > + a->dev = attachment->dev; > > + attachment->priv = a; > > + > > + return 0; > > +err: > > + kfree(a); > > + return rc; > > +} > > + > > +static void rstmem_dma_detach(struct dma_buf *dmabuf, > > + struct dma_buf_attachment *attachment) > > +{ > > + struct tee_rstmem_attachment *a = attachment->priv; > > + > > + sg_free_table(&a->table); > > + kfree(a); > > +} > > + > > +static struct sg_table * > > +rstmem_dma_map_dma_buf(struct dma_buf_attachment *attachment, > > + enum dma_data_direction direction) > > +{ > > + struct tee_rstmem_attachment *a = attachment->priv; > > + int ret; > > + > > + ret = dma_map_sgtable(attachment->dev, &a->table, direction, > > + DMA_ATTR_SKIP_CPU_SYNC); > > + if (ret) > > + return ERR_PTR(ret); > > + > > + return &a->table; > > +} > > + > > +static void rstmem_dma_unmap_dma_buf(struct dma_buf_attachment *attachment, > > + struct sg_table *table, > > + enum dma_data_direction direction) > > +{ > > + struct tee_rstmem_attachment *a = attachment->priv; > > + > > + WARN_ON(&a->table != table); > > + > > + dma_unmap_sgtable(attachment->dev, table, direction, > > + DMA_ATTR_SKIP_CPU_SYNC); > > +} > > + > > +static int rstmem_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > > + enum dma_data_direction direction) > > +{ > > + return -EPERM; > > +} > > + > > +static int rstmem_dma_buf_end_cpu_access(struct dma_buf *dmabuf, > > + enum dma_data_direction direction) > > +{ > > + return -EPERM; > > +} > > + > > +static int rstmem_dma_buf_mmap(struct dma_buf *dmabuf, > > + struct vm_area_struct *vma) > > +{ > > + return -EPERM; > > Just an aside, you should just not implment mmap if it's not possible. > Then you also don't need the cpu access functions. Both userspace mmap and > in-kernel vmap support is intentionally optional for dma-buf. Got it, thanks. I'll remove those in the next version. Cheers, Jens > -Sima > > > +} > > + > > +static void rstmem_dma_buf_free(struct dma_buf *dmabuf) > > +{ > > + struct tee_shm *shm = dmabuf->priv; > > + > > + tee_shm_put(shm); > > +} > > + > > +static const struct dma_buf_ops rstmem_generic_buf_ops = { > > + .attach = rstmem_dma_attach, > > + .detach = rstmem_dma_detach, > > + .map_dma_buf = rstmem_dma_map_dma_buf, > > + .unmap_dma_buf = rstmem_dma_unmap_dma_buf, > > + .begin_cpu_access = rstmem_dma_buf_begin_cpu_access, > > + .end_cpu_access = rstmem_dma_buf_end_cpu_access, > > + .mmap = rstmem_dma_buf_mmap, > > + .release = rstmem_dma_buf_free, > > +}; > > + > > +struct dma_buf *tee_rstmem_alloc(struct tee_context *ctx, u32 flags, > > + u32 use_case, size_t size, int *shm_id) > > +{ > > + struct tee_device *teedev = ctx->teedev; > > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); > > + struct dma_buf *dmabuf; > > + struct tee_shm *shm; > > + void *ret; > > + int rc; > > + > > + if (!tee_device_get(teedev)) > > + return ERR_PTR(-EINVAL); > > + > > + if (!teedev->desc->ops->rstmem_alloc || > > + !teedev->desc->ops->rstmem_free) { > > + dmabuf = ERR_PTR(-EINVAL); > > + goto err; > > + } > > + > > + shm = kzalloc(sizeof(*shm), GFP_KERNEL); > > + if (!shm) { > > + dmabuf = ERR_PTR(-ENOMEM); > > + goto err; > > + } > > + > > + refcount_set(&shm->refcount, 1); > > + shm->flags = TEE_SHM_RESTRICTED; > > + shm->use_case = use_case; > > + shm->ctx = ctx; > > + > > + mutex_lock(&teedev->mutex); > > + shm->id = idr_alloc(&teedev->idr, NULL, 1, 0, GFP_KERNEL); > > + mutex_unlock(&teedev->mutex); > > + if (shm->id < 0) { > > + dmabuf = ERR_PTR(shm->id); > > + goto err_kfree; > > + } > > + > > + rc = teedev->desc->ops->rstmem_alloc(ctx, shm, flags, use_case, size); > > + if (rc) { > > + dmabuf = ERR_PTR(rc); > > + goto err_idr_remove; > > + } > > + > > + mutex_lock(&teedev->mutex); > > + ret = idr_replace(&teedev->idr, shm, shm->id); > > + mutex_unlock(&teedev->mutex); > > + if (IS_ERR(ret)) { > > + dmabuf = ret; > > + goto err_rstmem_free; > > + } > > + teedev_ctx_get(ctx); > > + > > + exp_info.ops = &rstmem_generic_buf_ops; > > + exp_info.size = shm->size; > > + exp_info.priv = shm; > > + dmabuf = dma_buf_export(&exp_info); > > + if (IS_ERR(dmabuf)) { > > + tee_shm_put(shm); > > + return dmabuf; > > + } > > + > > + *shm_id = shm->id; > > + return dmabuf; > > + > > +err_rstmem_free: > > + teedev->desc->ops->rstmem_free(ctx, shm); > > +err_idr_remove: > > + mutex_lock(&teedev->mutex); > > + idr_remove(&teedev->idr, shm->id); > > + mutex_unlock(&teedev->mutex); > > +err_kfree: > > + kfree(shm); > > +err: > > + tee_device_put(teedev); > > + return dmabuf; > > +} > > diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c > > index daf6e5cfd59a..416f7f25d885 100644 > > --- a/drivers/tee/tee_shm.c > > +++ b/drivers/tee/tee_shm.c > > @@ -55,6 +55,8 @@ static void tee_shm_release(struct tee_device *teedev, struct tee_shm *shm) > > "unregister shm %p failed: %d", shm, rc); > > > > release_registered_pages(shm); > > + } else if (shm->flags & TEE_SHM_RESTRICTED) { > > + teedev->desc->ops->rstmem_free(shm->ctx, shm); > > } > > > > teedev_ctx_put(shm->ctx); > > diff --git a/drivers/tee/tee_shm_pool.c b/drivers/tee/tee_shm_pool.c > > index 80004b55628d..ee57ef157a77 100644 > > --- a/drivers/tee/tee_shm_pool.c > > +++ b/drivers/tee/tee_shm_pool.c > > @@ -1,9 +1,8 @@ > > // SPDX-License-Identifier: GPL-2.0-only > > /* > > - * Copyright (c) 2015, 2017, 2022 Linaro Limited > > + * Copyright (c) 2015, 2017, 2022, 2024 Linaro Limited > > */ > > #include <linux/device.h> > > -#include <linux/dma-buf.h> > > #include <linux/genalloc.h> > > #include <linux/slab.h> > > #include <linux/tee_core.h> > > @@ -90,3 +89,69 @@ struct tee_shm_pool *tee_shm_pool_alloc_res_mem(unsigned long vaddr, > > return ERR_PTR(rc); > > } > > EXPORT_SYMBOL_GPL(tee_shm_pool_alloc_res_mem); > > + > > +static int rstmem_pool_op_gen_alloc(struct tee_shm_pool *pool, > > + struct tee_shm *shm, size_t size, > > + size_t align) > > +{ > > + size_t sz = ALIGN(size, PAGE_SIZE); > > + phys_addr_t pa; > > + > > + pa = gen_pool_alloc(pool->private_data, sz); > > + if (!pa) > > + return -ENOMEM; > > + > > + shm->size = sz; > > + shm->paddr = pa; > > + > > + return 0; > > +} > > + > > +static void rstmem_pool_op_gen_free(struct tee_shm_pool *pool, > > + struct tee_shm *shm) > > +{ > > + gen_pool_free(pool->private_data, shm->paddr, shm->size); > > + shm->paddr = 0; > > +} > > + > > +static struct tee_shm_pool_ops rstmem_pool_ops_generic = { > > + .alloc = rstmem_pool_op_gen_alloc, > > + .free = rstmem_pool_op_gen_free, > > + .destroy_pool = pool_op_gen_destroy_pool, > > +}; > > + > > +struct tee_shm_pool *tee_rstmem_gen_pool_alloc(phys_addr_t paddr, size_t size) > > +{ > > + const size_t page_mask = PAGE_SIZE - 1; > > + struct tee_shm_pool *pool; > > + int rc; > > + > > + /* Check it's page aligned */ > > + if ((paddr | size) & page_mask) > > + return ERR_PTR(-EINVAL); > > + > > + pool = kzalloc(sizeof(*pool), GFP_KERNEL); > > + if (!pool) > > + return ERR_PTR(-ENOMEM); > > + > > + pool->private_data = gen_pool_create(PAGE_SHIFT, -1); > > + if (!pool->private_data) { > > + rc = -ENOMEM; > > + goto err_free; > > + } > > + > > + rc = gen_pool_add(pool->private_data, paddr, size, -1); > > + if (rc) > > + goto err_free_pool; > > + > > + pool->ops = &rstmem_pool_ops_generic; > > + return pool; > > + > > +err_free_pool: > > + gen_pool_destroy(pool->private_data); > > +err_free: > > + kfree(pool); > > + > > + return ERR_PTR(rc); > > +} > > +EXPORT_SYMBOL_GPL(tee_rstmem_gen_pool_alloc); > > diff --git a/include/linux/tee_core.h b/include/linux/tee_core.h > > index a38494d6b5f4..608302f494fe 100644 > > --- a/include/linux/tee_core.h > > +++ b/include/linux/tee_core.h > > @@ -26,6 +26,7 @@ > > #define TEE_SHM_USER_MAPPED BIT(1) /* Memory mapped in user space */ > > #define TEE_SHM_POOL BIT(2) /* Memory allocated from pool */ > > #define TEE_SHM_PRIV BIT(3) /* Memory private to TEE driver */ > > +#define TEE_SHM_RESTRICTED BIT(4) /* Restricted memory */ > > > > #define TEE_DEVICE_FLAG_REGISTERED 0x1 > > #define TEE_MAX_DEV_NAME_LEN 32 > > @@ -76,6 +77,8 @@ struct tee_device { > > * @supp_send: called for supplicant to send a response > > * @shm_register: register shared memory buffer in TEE > > * @shm_unregister: unregister shared memory buffer in TEE > > + * @rstmem_alloc: allocate restricted memory > > + * @rstmem_free: free restricted memory > > */ > > struct tee_driver_ops { > > void (*get_version)(struct tee_device *teedev, > > @@ -99,6 +102,9 @@ struct tee_driver_ops { > > struct page **pages, size_t num_pages, > > unsigned long start); > > int (*shm_unregister)(struct tee_context *ctx, struct tee_shm *shm); > > + int (*rstmem_alloc)(struct tee_context *ctx, struct tee_shm *shm, > > + u32 flags, u32 use_case, size_t size); > > + void (*rstmem_free)(struct tee_context *ctx, struct tee_shm *shm); > > }; > > > > /** > > @@ -229,6 +235,15 @@ static inline void tee_shm_pool_free(struct tee_shm_pool *pool) > > pool->ops->destroy_pool(pool); > > } > > > > +/** > > + * tee_rstmem_gen_pool_alloc() - Create a restricted memory manager > > + * @paddr: Physical address of start of pool > > + * @size: Size in bytes of the pool > > + * > > + * @returns pointer to a 'struct tee_shm_pool' or an ERR_PTR on failure. > > + */ > > +struct tee_shm_pool *tee_rstmem_gen_pool_alloc(phys_addr_t paddr, size_t size); > > + > > /** > > * tee_get_drvdata() - Return driver_data pointer > > * @returns the driver_data pointer supplied to tee_register(). > > diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h > > index a54c203000ed..cba067715d14 100644 > > --- a/include/linux/tee_drv.h > > +++ b/include/linux/tee_drv.h > > @@ -55,6 +55,7 @@ struct tee_context { > > * @pages: locked pages from userspace > > * @num_pages: number of locked pages > > * @refcount: reference counter > > + * @use_case: defined by TEE_IOC_UC_* in tee.h > > * @flags: defined by TEE_SHM_* in tee_core.h > > * @id: unique id of a shared memory object on this device, shared > > * with user space > > @@ -71,6 +72,7 @@ struct tee_shm { > > struct page **pages; > > size_t num_pages; > > refcount_t refcount; > > + u32 use_case; > > u32 flags; > > int id; > > u64 sec_world_id; > > diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h > > index d0430bee8292..88834448debb 100644 > > --- a/include/uapi/linux/tee.h > > +++ b/include/uapi/linux/tee.h > > @@ -1,5 +1,5 @@ > > /* > > - * Copyright (c) 2015-2016, Linaro Limited > > + * Copyright (c) 2015-2017, 2020, 2024, Linaro Limited > > * All rights reserved. > > * > > * Redistribution and use in source and binary forms, with or without > > @@ -48,6 +48,7 @@ > > #define TEE_GEN_CAP_PRIVILEGED (1 << 1)/* Privileged device (for supplicant) */ > > #define TEE_GEN_CAP_REG_MEM (1 << 2)/* Supports registering shared memory */ > > #define TEE_GEN_CAP_MEMREF_NULL (1 << 3)/* NULL MemRef support */ > > +#define TEE_GEN_CAP_RSTMEM (1 << 4)/* Supports restricted memory */ > > > > #define TEE_MEMREF_NULL (__u64)(-1) /* NULL MemRef Buffer */ > > > > @@ -389,6 +390,47 @@ struct tee_ioctl_shm_register_data { > > */ > > #define TEE_IOC_SHM_REGISTER _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 9, \ > > struct tee_ioctl_shm_register_data) > > + > > +#define TEE_IOC_UC_RESERVED 0 > > +#define TEE_IOC_UC_SECURE_VIDEO_PLAY 1 > > +#define TEE_IOC_UC_TRUSTED_UI 2 > > +#define TEE_IOC_UC_SECURE_VIDEO_RECORD 3 > > + > > +/** > > + * struct tee_ioctl_rstmem_alloc_data - Restricted memory allocate argument > > + * @size: [in/out] Size of restricted memory to allocate > > + * @flags: [in/out] Flags to/from allocate > > + * @use_case [in] Restricted memory use case, TEE_IOC_UC_* > > + * @id: [out] Identifier of the restricted memory > > + */ > > +struct tee_ioctl_rstmem_alloc_data { > > + __u64 size; > > + __u32 flags; > > + __u32 use_case; > > + __s32 id; > > +}; > > + > > +/** > > + * TEE_IOC_RSTMEM_ALLOC - allocate restricted memory > > + * > > + * Allocates restricted physically memory normally not accessible by the > > + * kernel. > > + * > > + * Restricted memory refers to memory buffers behind a hardware enforced > > + * firewall. It is not accessible to the kernel during normal circumstances > > + * but rather only accessible to certain hardware IPs or CPUs executing in > > + * higher privileged mode than the kernel itself. This interface allows to > > + * allocate and manage such restricted memory buffers via interaction with > > + * a TEE implementation. > > + * > > + * Returns a file descriptor on success or < 0 on failure > > + * > > + * The returned file descriptor is a dma-buf that can be attached and > > + * mapped for device with permission to access the physical memory. > > + */ > > +#define TEE_IOC_RSTMEM_ALLOC _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 10, \ > > + struct tee_ioctl_rstmem_alloc_data) > > + > > /* > > * Five syscalls are used when communicating with the TEE driver. > > * open(): opens the device associated with the driver > > -- > > 2.43.0 > > > > -- > Simona Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch

5 months, 2 weeks

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Sumit Garg

On Wed, 8 Jan 2025 at 22:27, Simona Vetter <simona.vetter(a)ffwll.ch> wrote: > > On Tue, Dec 24, 2024 at 12:05:19PM +0530, Sumit Garg wrote: > > Hi Simona, > > > > On Wed, 18 Dec 2024 at 16:36, Simona Vetter <simona.vetter(a)ffwll.ch> wrote: > > > > > > On Tue, Dec 17, 2024 at 11:07:36AM +0100, Jens Wiklander wrote: > > > > Hi, > > > > > > > > This patch set allocates the restricted DMA-bufs via the TEE subsystem. > > > > > > > > The TEE subsystem handles the DMA-buf allocations since it is the TEE > > > > (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the > > > > restrictions for the memory used for the DMA-bufs. > > > > > > > > I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted > > > > DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose > > > > how to allocate the restricted physical memory. > > > > > > > > TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also > > > > a use-case parameter. This is used by the backend TEE driver to decide on > > > > allocation policy and which devices should be able to access the memory. > > > > > > > > Three use-cases (Secure Video Playback, Trusted UI, and Secure Video > > > > Recording) has been identified so far to serve as examples of what can be > > > > expected. More use-cases can be added in userspace ABI, but it's up to the > > > > backend TEE drivers to provide the implementation. > > > > > > > > Each use-case has it's own restricted memory pool since different use-cases > > > > requires isolation from different parts of the system. A restricted memory > > > > pool can be based on a static carveout instantiated while probing the TEE > > > > backend driver, or dynamically allocated from CMA and made restricted as > > > > needed by the TEE. > > > > > > > > This can be tested on QEMU with the following steps: > > > > repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ > > > > -b prototype/sdp-v4 > > > > repo sync -j8 > > > > cd build > > > > make toolchains -j$(nproc) > > > > make SPMC_AT_EL=1 all -j$(nproc) > > > > make SPMC_AT_EL=1 run-only > > > > # login and at the prompt: > > > > xtest --sdp-basic > > > > > > > > The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at > > > > S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test > > > > without FF-A using the original SMC ABI instead. Please remember to do > > > > %rm -rf ../trusted-firmware-a/build/qemu > > > > for TF-A to be rebuilt properly using the new configuration. > > > > > > > > https://optee.readthedocs.io/en/latest/building/prerequisites.html > > > > list dependencies needed to build the above. > > > > > > > > The tests are pretty basic, mostly checking that a Trusted Application in > > > > the secure world can access and manipulate the memory. There are also some > > > > negative tests for out of bounds buffers etc. > > > > > > I think I've dropped this on earlier encrypted dma-buf discussions for > > > TEE, but can't find one right now ... > > > > Thanks for raising this query. > > > > > > > > Do we have some open source userspace for this? To my knowledge we have > > > two implementations of encrypted/content protected dma-buf in upstream > > > right now in the amd and intel gpu drivers, and unless I'm mistaken they > > > both have some minimal userspace supporting EXT_protected_textures: > > > > First of all to clarify the support Jens is adding here for allocating > > restricted shared memory allocation in TEE subsystem is meant to be > > generic and not specific to only secure media pipeline use-case. Then > > here we not only have open source test applications but rather open > > source firmware too (OP-TEE as a Trusted OS) [1] supporting this as a > > core feature where we maintain a stable and extensible ABI among the > > kernel and the OP-TEE core. > > > > Restricted memory is a feature enforced by hardware specific firewalls > > where a particular TEE implementation governs which particular block > > of memory is accessible to a particular peripheral or a CPU running in > > a higher privileged mode than the Linux kernel. There can be numeric > > use-cases surrounding that as follows: > > > > - Secure media pipeline where the contents gets decrypted and stored > > in a restricted buffer which are then accessible only to media display > > pipeline peripherals. > > - Trusted user interface where a peripheral takes input from the user > > and stores it in a restricted buffer which then is accessible to TEE > > implementation only. > > - Another possible use-case can be for the TEE implementation to store > > key material in a restricted buffer which is only accessible to the > > hardware crypto accelerator. > > > > I am sure there will be more use-cases related to this feature but > > those will only be possible once we provide a stable and extensible > > restricted memory interface among the Linux user-space and the secure > > world user-space (normally referred to as Trusted Applications). > > > > [1] https://github.com/OP-TEE/optee_os/pull/7159 > > > > > > > > https://github.com/KhronosGroup/OpenGL-Registry/blob/main/extensions/EXT/EX… > > > > > > It's not great, but it does just barely clear the bar in my opinion. I > > > guess something in gstreamer or similar video pipeline framework would > > > also do the job. > > > > > > Especially with the context of the uapi discussion in the v1/RFC thread I > > > think we need more than a bare-bones testcase to make sure this works in > > > actual use. > > > > Currently the TEE subsystem already supports a stable ABI for shared > > memory allocator among Linux user-space and secure world user-space > > here [2]. And the stable ABI for restricted memory is also along the > > same lines meant to be a vendor neutral abstraction for the user-space > > access. The current test cases not only test the interface but also > > perform regression tests too. > > > > I am also in favour of end to end open source use-cases. But I fear > > without progressing in a step wise manner as with this proposal we > > would rather force developers to upstream all the software pieces in > > one go which will be kind of a chicken and egg situation. I am sure > > once this feature lands Mediatek folks will be interested to port > > their secure video playback patchset [3] on top of it. Similarly other > > silicon vendors like NXP, Qcom etc. will be motivated to do the same. > > > > [2] https://docs.kernel.org/userspace-api/tee.html > > [3] https://lore.kernel.org/linux-arm-kernel/20240515112308.10171-1-yong.wu@med… > > We get entire opengl/vulkan driver stacks ready before we merge new drm > drivers, I really don't think this is too hard from a technical pov. And I > think the mediatek patches had the same issue of lacking userspace for it, > so that's not moving things forward. > -Sima > Okay fair enough, I think I get your point. Currently we are missing at least one peripheral support being the consumer for these restricted DMA-bufs. So I discussed with Jens offline that we can try with a crypto peripheral use-case first which can simply be demonstrated using the current OP-TEE client user-space. Also, in crypto peripheral use-case we can target the symmetric crypto use-case first which already has a concept of hardware backed symmetric key [1]. IOW, we should be able to come up with a generic symmetric crypto algorithm which can be supported by different crypto accelerators using a TEE backed restricted key DMA buffer. [1] https://www.youtube.com/watch?v=GbcpwUBFGDw -Sumit

5 months, 2 weeks

Re: [RFC PATCH 08/12] vfio/pci: Create host unaccessible dma-buf for private device

by Jason Gunthorpe

On Tue, Jan 07, 2025 at 10:27:15PM +0800, Xu Yilun wrote: > Add a flag for ioctl(VFIO_DEVICE_BIND_IOMMUFD) to mark a device as > for private assignment. For these private assigned devices, disallow > host accessing their MMIO resources. Why? Shouldn't the VMM simply not call mmap? Why does the kernel have to enforce this? Jason

5 months, 3 weeks

[PATCH 6.12 080/114] drm/xe: Move the coredump registration to the worker thread

by Greg Kroah-Hartman

6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: John Harrison <John.C.Harrison(a)Intel.com> [ Upstream commit 5dce85fecb87751ec94526e1ac516dd7871e2e0c ] Adding lockdep checking to the coredump code showed that there was an existing violation. The dev_coredumpm_timeout() call is used to register the dump with the base coredump subsystem. However, that makes multiple memory allocations, only some of which use the GFP_ flags passed in. So that also needs to be deferred to the worker function where it is safe to allocate with arbitrary flags. In order to not add protoypes for the callback functions, moving the _timeout call also means moving the worker thread function to later in the file. v2: Rebased after other changes to the worker function. Fixes: e799485044cb ("drm/xe: Introduce the dev_coredump infrastructure.") Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Francois Dugast <francois.dugast(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: "Thomas Hellström" <thomas.hellstrom(a)linux.intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: intel-xe(a)lists.freedesktop.org Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241128210824.3302147-3-John… (cherry picked from commit 90f51a7f4ec1004fc4ddfbc6d1f1068d85ef4771) Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/xe/xe_devcoredump.c | 73 +++++++++++++++-------------- 1 file changed, 39 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c index c40c91e27f71..c18e463092af 100644 --- a/drivers/gpu/drm/xe/xe_devcoredump.c +++ b/drivers/gpu/drm/xe/xe_devcoredump.c @@ -144,36 +144,6 @@ static void xe_devcoredump_snapshot_free(struct xe_devcoredump_snapshot *ss) ss->vm = NULL; } -static void xe_devcoredump_deferred_snap_work(struct work_struct *work) -{ - struct xe_devcoredump_snapshot *ss = container_of(work, typeof(*ss), work); - struct xe_devcoredump *coredump = container_of(ss, typeof(*coredump), snapshot); - struct xe_device *xe = coredump_to_xe(coredump); - unsigned int fw_ref; - - xe_pm_runtime_get(xe); - - /* keep going if fw fails as we still want to save the memory and SW data */ - fw_ref = xe_force_wake_get(gt_to_fw(ss->gt), XE_FORCEWAKE_ALL); - if (!xe_force_wake_ref_has_domain(fw_ref, XE_FORCEWAKE_ALL)) - xe_gt_info(ss->gt, "failed to get forcewake for coredump capture\n"); - xe_vm_snapshot_capture_delayed(ss->vm); - xe_guc_exec_queue_snapshot_capture_delayed(ss->ge); - xe_force_wake_put(gt_to_fw(ss->gt), fw_ref); - - xe_pm_runtime_put(xe); - - /* Calculate devcoredump size */ - ss->read.size = __xe_devcoredump_read(NULL, INT_MAX, coredump); - - ss->read.buffer = kvmalloc(ss->read.size, GFP_USER); - if (!ss->read.buffer) - return; - - __xe_devcoredump_read(ss->read.buffer, ss->read.size, coredump); - xe_devcoredump_snapshot_free(ss); -} - static ssize_t xe_devcoredump_read(char *buffer, loff_t offset, size_t count, void *data, size_t datalen) { @@ -222,6 +192,45 @@ static void xe_devcoredump_free(void *data) "Xe device coredump has been deleted.\n"); } +static void xe_devcoredump_deferred_snap_work(struct work_struct *work) +{ + struct xe_devcoredump_snapshot *ss = container_of(work, typeof(*ss), work); + struct xe_devcoredump *coredump = container_of(ss, typeof(*coredump), snapshot); + struct xe_device *xe = coredump_to_xe(coredump); + unsigned int fw_ref; + + /* + * NB: Despite passing a GFP_ flags parameter here, more allocations are done + * internally using GFP_KERNEL expliictly. Hence this call must be in the worker + * thread and not in the initial capture call. + */ + dev_coredumpm_timeout(gt_to_xe(ss->gt)->drm.dev, THIS_MODULE, coredump, 0, GFP_KERNEL, + xe_devcoredump_read, xe_devcoredump_free, + XE_COREDUMP_TIMEOUT_JIFFIES); + + xe_pm_runtime_get(xe); + + /* keep going if fw fails as we still want to save the memory and SW data */ + fw_ref = xe_force_wake_get(gt_to_fw(ss->gt), XE_FORCEWAKE_ALL); + if (!xe_force_wake_ref_has_domain(fw_ref, XE_FORCEWAKE_ALL)) + xe_gt_info(ss->gt, "failed to get forcewake for coredump capture\n"); + xe_vm_snapshot_capture_delayed(ss->vm); + xe_guc_exec_queue_snapshot_capture_delayed(ss->ge); + xe_force_wake_put(gt_to_fw(ss->gt), fw_ref); + + xe_pm_runtime_put(xe); + + /* Calculate devcoredump size */ + ss->read.size = __xe_devcoredump_read(NULL, INT_MAX, coredump); + + ss->read.buffer = kvmalloc(ss->read.size, GFP_USER); + if (!ss->read.buffer) + return; + + __xe_devcoredump_read(ss->read.buffer, ss->read.size, coredump); + xe_devcoredump_snapshot_free(ss); +} + static void devcoredump_snapshot(struct xe_devcoredump *coredump, struct xe_sched_job *job) { @@ -305,10 +314,6 @@ void xe_devcoredump(struct xe_sched_job *job) drm_info(&xe->drm, "Xe device coredump has been created\n"); drm_info(&xe->drm, "Check your /sys/class/drm/card%d/device/devcoredump/data\n", xe->drm.primary->index); - - dev_coredumpm_timeout(xe->drm.dev, THIS_MODULE, coredump, 0, GFP_KERNEL, - xe_devcoredump_read, xe_devcoredump_free, - XE_COREDUMP_TIMEOUT_JIFFIES); } static void xe_driver_devcoredump_fini(void *arg) -- 2.39.5

5 months, 4 weeks

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Sumit Garg

Hi Lukas, On Tue, 24 Dec 2024 at 14:58, Lukas Wunner <lukas(a)wunner.de> wrote: > > On Tue, Dec 24, 2024 at 12:05:19PM +0530, Sumit Garg wrote: > > Restricted memory is a feature enforced by hardware specific firewalls > > where a particular TEE implementation governs which particular block > > of memory is accessible to a particular peripheral or a CPU running in > > a higher privileged mode than the Linux kernel. > [...] > > - Another possible use-case can be for the TEE implementation to store > > key material in a restricted buffer which is only accessible to the > > hardware crypto accelerator. > > Just a heads-up: > > For RSA sign/verify operations using rsassa-pkcs1 encoding, > the message to be signed/verified (which I understand could > be located in restricted memory) is prepended by a padding. > > The crypto subsystem does the prepending of the padding in software. > The actual signature generation/verification (which is an RSA encrypt > or decrypt operation) may be performed in hardware by a crypto > accelerator. > > Before commit 8552cb04e083 ("crypto: rsassa-pkcs1 - Copy source > data for SG list"), the kernel constructed a scatterlist > consisting of the padding on the one hand, and of the message > to be signed/verified on the other hand. I believe this worked > for use cases where the message is located in restricted memory. > > However since that commit, the kernel kmalloc's a new buffer and > copies the message to be signed/verified into it. The argument > was that although the *kernel* may be able to access the data, > the crypto accelerator may *not* be able to do so. In particular, > portions of the padding are located in the kernel's .rodata section > which is a valid virtual address on x86 but not on arm64 and > which may be inaccessible to a crypto accelerator. > > However in the case of restricted memory, the situation is exactly > the opposite: The kernel may *not* be able to access the data, > but the crypto accelerator can access it just fine. > > I did raise a concern about this to the maintainer, but to no avail: > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@wunner.de/ Herbert's point is valid that there isn't any point for mapping restricted memory in the kernel virtual address space as any kernel access to that space can lead to platform specific hardware error scenarios. And for that reason we simply disallow dma_buf_mmap() and don't support dma_buf_vmap() for DMA-bufs holding TEE restricted memory. The only consumers for those DMA-bufs will be the DMA capable peripherals granted access permissions by the TEE implementation. IOW, kernel role here will be to just provide the DMA-buf infrastructure for buffers to be set up by TEE and then setting up DMA addresses for peripherals to access them. The hardware crypto accelerator can be one such peripheral. > > This is the alternative solution I would have preferred: > https://lore.kernel.org/r/3de5d373c86dcaa5abc36f501c1398c4fbf05f2f.17328651… > > > I am also in favour of end to end open source use-cases. But I fear > > without progressing in a step wise manner as with this proposal we > > would rather force developers to upstream all the software pieces in > > one go which will be kind of a chicken and egg situation. I am sure > > once this feature lands Mediatek folks will be interested to port > > their secure video playback patchset [3] on top of it. Similarly other > > silicon vendors like NXP, Qcom etc. will be motivated to do the same. > > The crypto use case may be easier to bring up than the video decoding > use case because you don't need to implement a huge amount of > user space code. Agree, if you already have such an existing hardware use-case then please feel free to build up on this patch-set. -Sumit > > Thanks, > > Lukas

6 months

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Dmitry Baryshkov

On Tue, Dec 24, 2024 at 10:32:41AM +0100, Lukas Wunner wrote: > On Tue, Dec 24, 2024 at 10:28:31AM +0100, Lukas Wunner wrote: > > I did raise a concern about this to the maintainer, but to no avail: > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@wunner.de/ > > Sorry, wrong link. This is the one I meant to copy-paste... :( > > https://lore.kernel.org/r/Z0rPxCGdD7r8HFKb@wunner.de/ Herbert asked a logical question, which got no response from your side. -- With best wishes Dmitry

6 months

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Sumit Garg

Hi Simona, On Wed, 18 Dec 2024 at 16:36, Simona Vetter <simona.vetter(a)ffwll.ch> wrote: > > On Tue, Dec 17, 2024 at 11:07:36AM +0100, Jens Wiklander wrote: > > Hi, > > > > This patch set allocates the restricted DMA-bufs via the TEE subsystem. > > > > The TEE subsystem handles the DMA-buf allocations since it is the TEE > > (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the > > restrictions for the memory used for the DMA-bufs. > > > > I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted > > DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose > > how to allocate the restricted physical memory. > > > > TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also > > a use-case parameter. This is used by the backend TEE driver to decide on > > allocation policy and which devices should be able to access the memory. > > > > Three use-cases (Secure Video Playback, Trusted UI, and Secure Video > > Recording) has been identified so far to serve as examples of what can be > > expected. More use-cases can be added in userspace ABI, but it's up to the > > backend TEE drivers to provide the implementation. > > > > Each use-case has it's own restricted memory pool since different use-cases > > requires isolation from different parts of the system. A restricted memory > > pool can be based on a static carveout instantiated while probing the TEE > > backend driver, or dynamically allocated from CMA and made restricted as > > needed by the TEE. > > > > This can be tested on QEMU with the following steps: > > repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ > > -b prototype/sdp-v4 > > repo sync -j8 > > cd build > > make toolchains -j$(nproc) > > make SPMC_AT_EL=1 all -j$(nproc) > > make SPMC_AT_EL=1 run-only > > # login and at the prompt: > > xtest --sdp-basic > > > > The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at > > S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test > > without FF-A using the original SMC ABI instead. Please remember to do > > %rm -rf ../trusted-firmware-a/build/qemu > > for TF-A to be rebuilt properly using the new configuration. > > > > https://optee.readthedocs.io/en/latest/building/prerequisites.html > > list dependencies needed to build the above. > > > > The tests are pretty basic, mostly checking that a Trusted Application in > > the secure world can access and manipulate the memory. There are also some > > negative tests for out of bounds buffers etc. > > I think I've dropped this on earlier encrypted dma-buf discussions for > TEE, but can't find one right now ... Thanks for raising this query. > > Do we have some open source userspace for this? To my knowledge we have > two implementations of encrypted/content protected dma-buf in upstream > right now in the amd and intel gpu drivers, and unless I'm mistaken they > both have some minimal userspace supporting EXT_protected_textures: First of all to clarify the support Jens is adding here for allocating restricted shared memory allocation in TEE subsystem is meant to be generic and not specific to only secure media pipeline use-case. Then here we not only have open source test applications but rather open source firmware too (OP-TEE as a Trusted OS) [1] supporting this as a core feature where we maintain a stable and extensible ABI among the kernel and the OP-TEE core. Restricted memory is a feature enforced by hardware specific firewalls where a particular TEE implementation governs which particular block of memory is accessible to a particular peripheral or a CPU running in a higher privileged mode than the Linux kernel. There can be numeric use-cases surrounding that as follows: - Secure media pipeline where the contents gets decrypted and stored in a restricted buffer which are then accessible only to media display pipeline peripherals. - Trusted user interface where a peripheral takes input from the user and stores it in a restricted buffer which then is accessible to TEE implementation only. - Another possible use-case can be for the TEE implementation to store key material in a restricted buffer which is only accessible to the hardware crypto accelerator. I am sure there will be more use-cases related to this feature but those will only be possible once we provide a stable and extensible restricted memory interface among the Linux user-space and the secure world user-space (normally referred to as Trusted Applications). [1] https://github.com/OP-TEE/optee_os/pull/7159 > > https://github.com/KhronosGroup/OpenGL-Registry/blob/main/extensions/EXT/EX… > > It's not great, but it does just barely clear the bar in my opinion. I > guess something in gstreamer or similar video pipeline framework would > also do the job. > > Especially with the context of the uapi discussion in the v1/RFC thread I > think we need more than a bare-bones testcase to make sure this works in > actual use. Currently the TEE subsystem already supports a stable ABI for shared memory allocator among Linux user-space and secure world user-space here [2]. And the stable ABI for restricted memory is also along the same lines meant to be a vendor neutral abstraction for the user-space access. The current test cases not only test the interface but also perform regression tests too. I am also in favour of end to end open source use-cases. But I fear without progressing in a step wise manner as with this proposal we would rather force developers to upstream all the software pieces in one go which will be kind of a chicken and egg situation. I am sure once this feature lands Mediatek folks will be interested to port their secure video playback patchset [3] on top of it. Similarly other silicon vendors like NXP, Qcom etc. will be motivated to do the same. [2] https://docs.kernel.org/userspace-api/tee.html [3] https://lore.kernel.org/linux-arm-kernel/20240515112308.10171-1-yong.wu@med… -Sumit > > Cheers, Sima > > > > > Thanks, > > Jens > > > > Changes since V3: > > * Make the use_case and flags field in struct tee_shm u32's instead of > > u16's > > * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file > > * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com > > * Added a note in the commit message for "optee: account for direction > > while converting parameters" why it's needed > > * Factor out dynamic restricted memory allocation from > > "optee: support restricted memory allocation" into two new commits > > "optee: FF-A: dynamic restricted memory allocation" and > > "optee: smc abi: dynamic restricted memory allocation" > > * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic > > restricted memory allocate if CMA isn't configured > > > > Changes since the V2 RFC: > > * Based on v6.12 > > * Replaced the flags for SVP and Trusted UID memory with a u32 field with > > unique id for each use case > > * Added dynamic allocation of restricted memory pools > > * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory > > * Added support for FF-A with FFA_LEND > > > > Changes since the V1 RFC: > > * Based on v6.11 > > * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC > > > > Changes since Olivier's post [2]: > > * Based on Yong Wu's post [1] where much of dma-buf handling is done in > > the generic restricted heap > > * Simplifications and cleanup > > * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap > > support" > > * Replaced the word "secure" with "restricted" where applicable > > > > Jens Wiklander (6): > > tee: add restricted memory allocation > > optee: account for direction while converting parameters > > optee: sync secure world ABI headers > > optee: support restricted memory allocation > > optee: FF-A: dynamic restricted memory allocation > > optee: smc abi: dynamic restricted memory allocation > > > > drivers/tee/Makefile | 1 + > > drivers/tee/optee/Makefile | 1 + > > drivers/tee/optee/call.c | 10 +- > > drivers/tee/optee/core.c | 1 + > > drivers/tee/optee/ffa_abi.c | 178 +++++++++++++- > > drivers/tee/optee/optee_ffa.h | 27 ++- > > drivers/tee/optee/optee_msg.h | 65 ++++- > > drivers/tee/optee/optee_private.h | 75 ++++-- > > drivers/tee/optee/optee_smc.h | 71 +++++- > > drivers/tee/optee/rpc.c | 31 ++- > > drivers/tee/optee/rstmem.c | 388 ++++++++++++++++++++++++++++++ > > drivers/tee/optee/smc_abi.c | 213 ++++++++++++++-- > > drivers/tee/tee_core.c | 38 ++- > > drivers/tee/tee_private.h | 2 + > > drivers/tee/tee_rstmem.c | 201 ++++++++++++++++ > > drivers/tee/tee_shm.c | 2 + > > drivers/tee/tee_shm_pool.c | 69 +++++- > > include/linux/tee_core.h | 15 ++ > > include/linux/tee_drv.h | 2 + > > include/uapi/linux/tee.h | 44 +++- > > 20 files changed, 1358 insertions(+), 76 deletions(-) > > create mode 100644 drivers/tee/optee/rstmem.c > > create mode 100644 drivers/tee/tee_rstmem.c > > > > > > base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 > > -- > > 2.43.0 > > > > -- > Simona Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch

6 months

[PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC takes in addition to a size and flags parameters also a use-case parameter. This is used by the backend TEE driver to decide on allocation policy and which devices should be able to access the memory. Three use-cases (Secure Video Playback, Trusted UI, and Secure Video Recording) has been identified so far to serve as examples of what can be expected. More use-cases can be added in userspace ABI, but it's up to the backend TEE drivers to provide the implementation. Each use-case has it's own restricted memory pool since different use-cases requires isolation from different parts of the system. A restricted memory pool can be based on a static carveout instantiated while probing the TEE backend driver, or dynamically allocated from CMA and made restricted as needed by the TEE. This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v4 repo sync -j8 cd build make toolchains -j$(nproc) make SPMC_AT_EL=1 all -j$(nproc) make SPMC_AT_EL=1 run-only # login and at the prompt: xtest --sdp-basic The SPMC_AT_EL=1 parameter configures the build with FF-A and an SPMC at S-EL1 inside OP-TEE. The parameter can be changed into SPMC_AT_EL=n to test without FF-A using the original SMC ABI instead. Please remember to do %rm -rf ../trusted-firmware-a/build/qemu for TF-A to be rebuilt properly using the new configuration. https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens Changes since V3: * Make the use_case and flags field in struct tee_shm u32's instead of u16's * Add more description for TEE_IOC_RSTMEM_ALLOC in the header file * Import namespace DMA_BUF in module tee, reported by lkp(a)intel.com * Added a note in the commit message for "optee: account for direction while converting parameters" why it's needed * Factor out dynamic restricted memory allocation from "optee: support restricted memory allocation" into two new commits "optee: FF-A: dynamic restricted memory allocation" and "optee: smc abi: dynamic restricted memory allocation" * Guard CMA usage with #ifdef CONFIG_CMA, effectively disabling dynamic restricted memory allocate if CMA isn't configured Changes since the V2 RFC: * Based on v6.12 * Replaced the flags for SVP and Trusted UID memory with a u32 field with unique id for each use case * Added dynamic allocation of restricted memory pools * Added OP-TEE ABI both with and without FF-A for dynamic restricted memory * Added support for FF-A with FFA_LEND Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (6): tee: add restricted memory allocation optee: account for direction while converting parameters optee: sync secure world ABI headers optee: support restricted memory allocation optee: FF-A: dynamic restricted memory allocation optee: smc abi: dynamic restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 10 +- drivers/tee/optee/core.c | 1 + drivers/tee/optee/ffa_abi.c | 178 +++++++++++++- drivers/tee/optee/optee_ffa.h | 27 ++- drivers/tee/optee/optee_msg.h | 65 ++++- drivers/tee/optee/optee_private.h | 75 ++++-- drivers/tee/optee/optee_smc.h | 71 +++++- drivers/tee/optee/rpc.c | 31 ++- drivers/tee/optee/rstmem.c | 388 ++++++++++++++++++++++++++++++ drivers/tee/optee/smc_abi.c | 213 ++++++++++++++-- drivers/tee/tee_core.c | 38 ++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 201 ++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 +++++- include/linux/tee_core.h | 15 ++ include/linux/tee_drv.h | 2 + include/uapi/linux/tee.h | 44 +++- 20 files changed, 1358 insertions(+), 76 deletions(-) create mode 100644 drivers/tee/optee/rstmem.c create mode 100644 drivers/tee/tee_rstmem.c base-commit: fac04efc5c793dccbd07e2d59af9f90b7fc0dca4 -- 2.43.0

6 months, 1 week

Re: [PATCH] drm/sched: Document run_job() refcount hazard

by Christian König

Am 20.12.24 um 15:51 schrieb Danilo Krummrich: > On Fri, Dec 20, 2024 at 03:11:34PM +0100, Philipp Stanner wrote: >> On Fri, 2024-12-20 at 14:25 +0100, Christian König wrote: >>> Am 20.12.24 um 14:18 schrieb Danilo Krummrich: >>>> On Fri, Dec 20, 2024 at 01:53:34PM +0100, Christian König wrote: >>>>> Am 20.12.24 um 13:45 schrieb Philipp Stanner: >>>>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c >>>>>> b/drivers/gpu/drm/scheduler/sched_main.c >>>>>> index 7ce25281c74c..d6f8df39d848 100644 >>>>>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>>>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>>>>> + * >>>>>> + * @sched_job: the job to run >>>>>> + * >>>>>> + * Returns: dma_fence the driver must signal once the >>>>>> hardware has >>>>>> + * completed the job ("hardware fence"). >>>>>> + * >>>>>> + * Note that the scheduler expects to 'inherit' its >>>>>> own reference to >>>>>> + * this fence from the callback. It does not invoke an >>>>>> extra >>>>>> + * dma_fence_get() on it. Consequently, this callback >>>>>> must return a >>>>>> + * fence whose refcount is at least 2: One for the >>>>>> scheduler's >>>>>> + * reference returned here, another one for the >>>>>> reference kept by the >>>>>> + * driver. >>>>> Well the driver actually doesn't need any extra reference. The >>>>> scheduler >>>>> just needs to guarantee that this reference isn't dropped before >>>>> it is >>>>> signaled. >>>> I think he means the reference the driver's fence context has to >>>> have in order >>>> to signal that thing eventually. >>> Yeah, but this is usually a weak reference. IIRC most drivers don't >>> increment the reference count for the reference they keep to signal a >>> fence. >>> >>> It's expected that the consumers of the dma_fence keep the fence >>> alive >>> at least until it is signaled. >> So are you saying that the driver having an extra reference (without >> having obtained it with dma_fence_get()) is not an issue because the >> driver is the one who will signal the fence [and then be done with it]? > It's never a "real" issue if you have multiple pointers to a reference counted > object as long as you can ensure that you hold at least one reference for the > time you have pointers to the object. Well, I'm not saying that this isn't an issue. I'm just pointing out that this is the current practice :) > But, that's bad design. For every pointer to an object a separate reference > should be taken. Yeah, completely agree. Weak references are usually a bad idea if you don't absolutely need them for something. Regards, Christian.

6 months, 1 week

Re: [PATCH] drm/sched: Document run_job() refcount hazard

by Christian König

Am 20.12.24 um 14:18 schrieb Danilo Krummrich: > On Fri, Dec 20, 2024 at 01:53:34PM +0100, Christian König wrote: >> Am 20.12.24 um 13:45 schrieb Philipp Stanner: >>> From: Philipp Stanner <pstanner(a)redhat.com> >>> >>> drm_sched_backend_ops.run_job() returns a dma_fence for the scheduler. >>> That fence is signalled by the driver once the hardware completed the >>> associated job. The scheduler does not increment the reference count on >>> that fence, but implicitly expects to inherit this fence from run_job(). >>> >>> This is relatively subtle and prone to misunderstandings. >>> >>> This implies that, to keep a reference for itself, a driver needs to >>> call dma_fence_get() in addition to dma_fence_init() in that callback. >>> >>> It's further complicated by the fact that the scheduler even decrements >>> the refcount in drm_sched_run_job_work() since it created a new >>> reference in drm_sched_fence_scheduled(). It does, however, still use >>> its pointer to the fence after calling dma_fence_put() - which is safe >>> because of the aforementioned new reference, but actually still violates >>> the refcounting rules. >>> >>> Improve the explanatory comment for that decrement. >>> >>> Move the call to dma_fence_put() to the position behind the last usage >>> of the fence. >>> >>> Document the necessity to increment the reference count in >>> drm_sched_backend_ops.run_job(). >>> >>> Cc: Christian König <christian.koenig(a)amd.com> >>> Cc: Tvrtko Ursulin <tursulin(a)ursulin.net> >>> Cc: Andrey Grodzovsky <andrey.grodzovsky(a)amd.com> >>> Signed-off-by: Philipp Stanner <pstanner(a)redhat.com> >>> --- >>> drivers/gpu/drm/scheduler/sched_main.c | 10 +++++++--- >>> include/drm/gpu_scheduler.h | 20 ++++++++++++++++---- >>> 2 files changed, 23 insertions(+), 7 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >>> index 7ce25281c74c..d6f8df39d848 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>> + * >>> + * @sched_job: the job to run >>> + * >>> + * Returns: dma_fence the driver must signal once the hardware has >>> + * completed the job ("hardware fence"). >>> + * >>> + * Note that the scheduler expects to 'inherit' its own reference to >>> + * this fence from the callback. It does not invoke an extra >>> + * dma_fence_get() on it. Consequently, this callback must return a >>> + * fence whose refcount is at least 2: One for the scheduler's >>> + * reference returned here, another one for the reference kept by the >>> + * driver. >> Well the driver actually doesn't need any extra reference. The scheduler >> just needs to guarantee that this reference isn't dropped before it is >> signaled. > I think he means the reference the driver's fence context has to have in order > to signal that thing eventually. Yeah, but this is usually a weak reference. IIRC most drivers don't increment the reference count for the reference they keep to signal a fence. It's expected that the consumers of the dma_fence keep the fence alive at least until it is signaled. That's why we have this nice warning in dma_fence_release(). On the other hand I completely agree it would be more defensive if drivers increment the reference count for the reference they keep for signaling. So if we want to document that the fence reference count should at least be 2 we somehow need to enforce this with a warning for example. Regards, Christian. > >> Regards, >> Christian. >> >>> */ >>> struct dma_fence *(*run_job)(struct drm_sched_job *sched_job);

6 months, 1 week

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig