| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240415-guppy-of-perpetual-current-3a7974@houat>
Date: Mon, 15 Apr 2024 11:37:10 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Shawn Sung <shawn.sung@...iatek.com>
Cc: Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>, Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>, dri-devel@...ts.freedesktop.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org,
"Jason-JH.Lin" <jason-jh.lin@...iatek.com>
Subject: Re: [PATCH v5 2/9] drm/mediatek: Add secure buffer control flow to
mtk_drm_gem
On Wed, Apr 03, 2024 at 06:26:54PM +0800, Shawn Sung wrote:
> From: "Jason-JH.Lin" <jason-jh.lin@...iatek.com>
>
> Add secure buffer control flow to mtk_drm_gem.
>
> When user space takes DRM_MTK_GEM_CREATE_ENCRYPTED flag and size
> to create a mtk_drm_gem object, mtk_drm_gem will find a matched size
> dma buffer from secure dma-heap and bind it to mtk_drm_gem object.
>
> Signed-off-by: Jason-JH.Lin <jason-jh.lin@...iatek.com>
> Signed-off-by: Hsiao Chien Sung <shawn.sung@...iatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_gem.c | 85 +++++++++++++++++++++++++++++-
> drivers/gpu/drm/mediatek/mtk_gem.h | 4 ++
> 2 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_gem.c b/drivers/gpu/drm/mediatek/mtk_gem.c
> index e59e0727717b7..ec34d02c14377 100644
> --- a/drivers/gpu/drm/mediatek/mtk_gem.c
> +++ b/drivers/gpu/drm/mediatek/mtk_gem.c
> @@ -4,6 +4,8 @@
> */
>
> #include <linux/dma-buf.h>
> +#include <linux/dma-heap.h>
> +#include <uapi/linux/dma-heap.h>
> #include <drm/mediatek_drm.h>
>
> #include <drm/drm.h>
> @@ -102,6 +104,81 @@ struct mtk_gem_obj *mtk_gem_create(struct drm_device *dev,
> return ERR_PTR(ret);
> }
>
> +struct mtk_gem_obj *mtk_gem_create_from_heap(struct drm_device *dev,
> + const char *heap, size_t size)
> +{
> + struct mtk_drm_private *priv = dev->dev_private;
> + struct mtk_gem_obj *mtk_gem;
> + struct drm_gem_object *obj;
> + struct dma_heap *dma_heap;
> + struct dma_buf *dma_buf;
> + struct dma_buf_attachment *attach;
> + struct sg_table *sgt;
> + struct iosys_map map = {};
> + int ret;
> +
> + mtk_gem = mtk_gem_init(dev, size);
> + if (IS_ERR(mtk_gem))
> + return ERR_CAST(mtk_gem);
> +
> + obj = &mtk_gem->base;
> +
> + dma_heap = dma_heap_find(heap);
> + if (!dma_heap) {
> + DRM_ERROR("heap find fail\n");
> + goto err_gem_free;
> + }
> + dma_buf = dma_heap_buffer_alloc(dma_heap, size,
> + O_RDWR | O_CLOEXEC, DMA_HEAP_VALID_HEAP_FLAGS);
> + if (IS_ERR(dma_buf)) {
> + DRM_ERROR("buffer alloc fail\n");
> + dma_heap_put(dma_heap);
> + goto err_gem_free;
> + }
> + dma_heap_put(dma_heap);
> +
> + attach = dma_buf_attach(dma_buf, priv->dma_dev);
> + if (IS_ERR(attach)) {
> + DRM_ERROR("attach fail, return\n");
> + dma_buf_put(dma_buf);
> + goto err_gem_free;
> + }
> +
> + sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> + if (IS_ERR(sgt)) {
> + DRM_ERROR("map failed, detach and return\n");
> + dma_buf_detach(dma_buf, attach);
> + dma_buf_put(dma_buf);
> + goto err_gem_free;
> + }
> + obj->import_attach = attach;
> + mtk_gem->dma_addr = sg_dma_address(sgt->sgl);
> + mtk_gem->sg = sgt;
> + mtk_gem->size = dma_buf->size;
> +
> + if (!strcmp(heap, "mtk_svp") || !strcmp(heap, "mtk_svp_cma")) {
> + /* secure buffer can not be mapped */
> + mtk_gem->secure = true;
> + } else {
> + ret = dma_buf_vmap(dma_buf, &map);
> + mtk_gem->kvaddr = map.vaddr;
> + if (ret) {
> + DRM_ERROR("map failed, ret=%d\n", ret);
> + dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
> + dma_buf_detach(dma_buf, attach);
> + dma_buf_put(dma_buf);
> + mtk_gem->kvaddr = NULL;
> + }
> + }
> +
> + return mtk_gem;
> +
> +err_gem_free:
> + drm_gem_object_release(obj);
> + kfree(mtk_gem);
> + return ERR_PTR(-ENOMEM);
> +}
> +
> void mtk_gem_free_object(struct drm_gem_object *obj)
> {
> struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
> @@ -229,7 +306,9 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
> if (IS_ERR(mtk_gem))
> return ERR_CAST(mtk_gem);
>
> + mtk_gem->secure = !sg_page(sg->sgl);
> mtk_gem->dma_addr = sg_dma_address(sg->sgl);
> + mtk_gem->size = attach->dmabuf->size;
> mtk_gem->sg = sg;
>
> return &mtk_gem->base;
> @@ -304,7 +383,11 @@ int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
> struct drm_mtk_gem_create *args = data;
> int ret;
>
> - mtk_gem = mtk_gem_create(dev, args->size, false);
> + if (args->flags & DRM_MTK_GEM_CREATE_ENCRYPTED)
> + mtk_gem = mtk_gem_create_from_heap(dev, "mtk_svp_cma", args->size);
That heap doesn't exist upstream either. Also, I'm wondering if it's the
right solution there.
From what I can tell, you want to allow to create encrypted buffers from
the TEE. Why do we need this as a DRM ioctl at all? A heap seems like
the perfect solution to do so, and then you just have to import it into
DRM.
I'm also not entirely sure that not having a SG list is enough to
consider the buffer secure. Wouldn't a buffer allocated without a kernel
mapping also be in that situation?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)
Powered by blists - more mailing lists