dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Joakim Bech <joakim.bech@linaro.org>
To: Yong Wu <yong.wu@mediatek.com>
Cc: Anan Sun <anan.sun@mediatek.com>,
	devicetree@vger.kernel.org, Conor Dooley <conor+dt@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	kuohong.wang@mediatek.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, christian.koenig@amd.com,
	linaro-mm-sig@lists.linaro.org, Rob Herring <robh+dt@kernel.org>,
	John Stultz <jstultz@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	jianjiao.zeng@mediatek.com,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	Sumit Semwal <sumit.semwal@linaro.org>,
	tjmercier@google.com,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH 6/9] dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing
Date: Wed, 27 Sep 2023 16:37:09 +0200	[thread overview]
Message-ID: <20230927143709.hrytde34trrdhpwf@pop-os.localdomain> (raw)
In-Reply-To: <20230911023038.30649-7-yong.wu@mediatek.com>

On Mon, Sep 11, 2023 at 10:30:35AM +0800, Yong Wu wrote:
> Add TEE service call for secure memory allocating/freeing.
> 
> Signed-off-by: Anan Sun <anan.sun@mediatek.com>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
>  drivers/dma-buf/heaps/mtk_secure_heap.c | 69 ++++++++++++++++++++++++-
>  1 file changed, 68 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c b/drivers/dma-buf/heaps/mtk_secure_heap.c
> index e3da33a3d083..14c2a16a7164 100644
> --- a/drivers/dma-buf/heaps/mtk_secure_heap.c
> +++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
> @@ -17,6 +17,9 @@
>  
>  #define MTK_TEE_PARAM_NUM		4
>  
> +#define TZCMD_MEM_SECURECM_UNREF	7
> +#define TZCMD_MEM_SECURECM_ZALLOC	15
This is related to the discussion around UUID as well. These numbers
here are specific to the MediaTek TA. If we could make things more
generic, then these should probably be 0 and 1. 

I also find the naming a bit heavy, I think I'd suggest something like:
# define TEE_CMD_SECURE_HEAP_ZALLOC ...
and so on.

> +
>  /*
>   * MediaTek secure (chunk) memory type
>   *
> @@ -29,6 +32,8 @@ enum kree_mem_type {
The "kree" here, is that meant to indicate kernel REE? If yes, then I
guess that could be dropped since we know we're already in the kernel
context, perhaps instead name it something with "secure_heap_type"?

>  struct mtk_secure_heap_buffer {
>  	struct dma_heap		*heap;
>  	size_t			size;
> +
> +	u32			sec_handle;
>  };
>  
>  struct mtk_secure_heap {
> @@ -80,6 +85,63 @@ static int mtk_kree_secure_session_init(struct mtk_secure_heap *sec_heap)
>  	return ret;
>  }
>  
> +static int
> +mtk_sec_mem_tee_service_call(struct tee_context *tee_ctx, u32 session,
> +			     unsigned int command, struct tee_param *params)
> +{
> +	struct tee_ioctl_invoke_arg arg = {0};
> +	int ret;
> +
> +	arg.num_params = MTK_TEE_PARAM_NUM;
> +	arg.session = session;
> +	arg.func = command;
> +
> +	ret = tee_client_invoke_func(tee_ctx, &arg, params);
> +	if (ret < 0 || arg.ret) {
> +		pr_err("%s: cmd %d ret %d:%x.\n", __func__, command, ret, arg.ret);
> +		ret = -EOPNOTSUPP;
> +	}
> +	return ret;
> +}
Perhaps not relevant for this patch set, but since this function is just
a pure TEE call, I'm inclined to suggest that this could even be moved
out as a generic TEE function. I.e., something that could be used
elsewhere in the Linux kernel.

> +
> +static int mtk_sec_mem_allocate(struct mtk_secure_heap *sec_heap,
> +				struct mtk_secure_heap_buffer *sec_buf)
> +{
> +	struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
> +	u32 mem_session = sec_heap->mem_session;
How about name it tee_session? Alternative ta_session? I think that
would better explain what it actually is.

> +	int ret;
> +
> +	params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> +	params[0].u.value.a = SZ_4K;			/* alignment */
> +	params[0].u.value.b = sec_heap->mem_type;	/* memory type */
> +	params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> +	params[1].u.value.a = sec_buf->size;
> +	params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT;
> +
> +	/* Always request zeroed buffer */
> +	ret = mtk_sec_mem_tee_service_call(sec_heap->tee_ctx, mem_session,
> +					   TZCMD_MEM_SECURECM_ZALLOC, params);
> +	if (ret)
> +		return -ENOMEM;
> +
> +	sec_buf->sec_handle = params[2].u.value.a;
> +	return 0;
> +}
> +
> +static void mtk_sec_mem_release(struct mtk_secure_heap *sec_heap,
> +				struct mtk_secure_heap_buffer *sec_buf)
> +{
> +	struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
> +	u32 mem_session = sec_heap->mem_session;
> +
> +	params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> +	params[0].u.value.a = sec_buf->sec_handle;
> +	params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
Perhaps worth having a comment for params[1] explain why we need the
VALUE_OUTPUT here?

-- 
// Regards
Joakim

> +
> +	mtk_sec_mem_tee_service_call(sec_heap->tee_ctx, mem_session,
> +				     TZCMD_MEM_SECURECM_UNREF, params);
> +}
> +
>  static struct dma_buf *
>  mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
>  		      unsigned long fd_flags, unsigned long heap_flags)
> @@ -107,6 +169,9 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
>  	sec_buf->size = size;
>  	sec_buf->heap = heap;
>  
> +	ret = mtk_sec_mem_allocate(sec_heap, sec_buf);
> +	if (ret)
> +		goto err_free_buf;
>  	exp_info.exp_name = dma_heap_get_name(heap);
>  	exp_info.size = sec_buf->size;
>  	exp_info.flags = fd_flags;
> @@ -115,11 +180,13 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
>  	dmabuf = dma_buf_export(&exp_info);
>  	if (IS_ERR(dmabuf)) {
>  		ret = PTR_ERR(dmabuf);
> -		goto err_free_buf;
> +		goto err_free_sec_mem;
>  	}
>  
>  	return dmabuf;
>  
> +err_free_sec_mem:
> +	mtk_sec_mem_release(sec_heap, sec_buf);
>  err_free_buf:
>  	kfree(sec_buf);
>  	return ERR_PTR(ret);
> -- 
> 2.25.1
> 

  parent reply	other threads:[~2023-09-27 14:37 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11  2:30 [PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap Yong Wu
2023-09-11  2:30 ` [PATCH 1/9] dma-buf: heaps: Deduplicate docs and adopt common format Yong Wu
2023-09-11  9:36   ` Christian König
2023-09-11 23:51     ` T.J. Mercier
2023-09-11  2:30 ` [PATCH 2/9] dma-heap: Add proper kref handling on dma-buf heaps Yong Wu
2023-09-11  9:48   ` Christian König
2023-09-22 18:19     ` T.J. Mercier
2023-09-11  2:30 ` [PATCH 3/9] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps Yong Wu
2023-09-11 10:13   ` Christian König
2023-09-11 18:29     ` John Stultz
2023-09-12  7:06       ` Christian König
2023-09-12  8:52         ` Yong Wu (吴勇)
2023-09-12 14:46           ` Christian König
2023-09-12 14:58             ` Nicolas Dufresne
2023-09-13  8:30               ` Christian König
2023-09-12 14:50     ` Nicolas Dufresne
2023-09-11 16:12   ` Nicolas Dufresne
2023-09-12  8:47     ` Yong Wu (吴勇)
2023-09-12 15:05       ` Nicolas Dufresne
2023-09-18 10:46         ` Yong Wu (吴勇)
2023-09-11  2:30 ` [PATCH 4/9] dma-buf: heaps: Initialise MediaTek secure heap Yong Wu
2023-09-11  8:05   ` kernel test robot
2023-09-27 14:42   ` Joakim Bech
2023-09-28  8:03     ` Yong Wu (吴勇)
2023-10-19  4:45   ` Vijayanand Jitta
2023-10-20  9:59     ` Yong Wu (吴勇)
2023-10-26  4:48       ` Vijayanand Jitta
2023-10-27  7:47         ` Yong Wu (吴勇)
2023-10-30  8:06           ` Vijayanand Jitta
2023-09-11  2:30 ` [PATCH 5/9] dma-buf: heaps: mtk_sec_heap: Initialise tee session Yong Wu
2023-09-11  9:29   ` AngeloGioacchino Del Regno
2023-09-11 10:15     ` Christian König
2023-09-12  6:17     ` Yong Wu (吴勇)
2023-09-12  9:32       ` AngeloGioacchino Del Regno
2023-09-25 12:49         ` Yong Wu (吴勇)
2023-09-27 13:46           ` Joakim Bech
2023-09-27 15:17             ` Benjamin Gaignard
2023-09-27 18:56               ` Jeffrey Kardatzke
2023-09-28  8:30                 ` Benjamin Gaignard
2023-09-28 17:48                   ` Jeffrey Kardatzke
2023-09-29  6:54                     ` Benjamin Gaignard
2023-10-13 19:09                       ` Jeffrey Kardatzke
2023-10-13 19:10                       ` Jeffrey Kardatzke
2023-09-27 18:54             ` Jeffrey Kardatzke
2023-09-13 13:35   ` kernel test robot
2023-09-11  2:30 ` [PATCH 6/9] dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing Yong Wu
2023-09-14 10:18   ` kernel test robot
2023-09-27 14:37   ` Joakim Bech [this message]
2023-09-28  5:24     ` Yong Wu (吴勇)
2023-10-19  4:45   ` Vijayanand Jitta
2023-10-20 10:01     ` Yong Wu (吴勇)
2023-09-11  2:30 ` [PATCH 7/9] dma-buf: heaps: mtk_sec_heap: Add dma_ops Yong Wu
2023-09-11  2:30 ` [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP Yong Wu
2023-09-11 15:44   ` Rob Herring
2023-09-12  6:16     ` Yong Wu (吴勇)
2023-09-12  8:28       ` Krzysztof Kozlowski
2023-09-12 10:13         ` Robin Murphy
2023-09-12 15:53           ` Rob Herring
2023-09-12 16:05             ` Robin Murphy
2023-09-18 10:47             ` Yong Wu (吴勇)
2023-09-19 22:15               ` Jeffrey Kardatzke
2023-10-12  6:54                 ` Yong Wu (吴勇)
2023-10-12  7:07                   ` Krzysztof Kozlowski
2023-10-12 11:15                     ` Yong Wu (吴勇)
2023-10-19  4:46   ` Vijayanand Jitta
2023-10-20  9:50     ` Yong Wu (吴勇)
2023-11-01  5:50       ` Jaskaran Singh
2023-11-06  5:56         ` Yong Wu (吴勇)
2023-11-20  8:20           ` Jaskaran Singh
2023-09-11  2:30 ` [PATCH 9/9] dma_buf: heaps: mtk_sec_heap: Add a new CMA heap Yong Wu
2023-09-11  9:33   ` AngeloGioacchino Del Regno
2023-10-19  4:44 ` [PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap Vijayanand Jitta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230927143709.hrytde34trrdhpwf@pop-os.localdomain \
    --to=joakim.bech@linaro.org \
    --cc=anan.sun@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jianjiao.zeng@mediatek.com \
    --cc=jstultz@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    --cc=yong.wu@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).