| 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: <20240131135343.rj6xlch6zcev2v47@pop-os.localdomain>
Date: Wed, 31 Jan 2024 14:53:43 +0100
From: Joakim Bech <joakim.bech@...aro.org>
To: Yong Wu <yong.wu@...iatek.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>, christian.koenig@....com,
Sumit Semwal <sumit.semwal@...aro.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Benjamin Gaignard <benjamin.gaignard@...labora.com>,
Brian Starkey <Brian.Starkey@....com>,
John Stultz <jstultz@...gle.com>, tjmercier@...gle.com,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
Robin Murphy <robin.murphy@....com>,
Vijayanand Jitta <quic_vjitta@...cinc.com>,
Jeffrey Kardatzke <jkardatzke@...gle.com>,
Pavel Machek <pavel@....cz>, Simon Ser <contact@...rsion.fr>,
Pekka Paalanen <ppaalanen@...il.com>, jianjiao.zeng@...iatek.com,
kuohong.wang@...iatek.com, youlin.pei@...iatek.com
Subject: Re: [PATCH v4 3/7] dma-buf: heaps: restricted_heap: Add private heap
ops
On Fri, Jan 12, 2024 at 05:20:10PM +0800, Yong Wu wrote:
> Add "struct restricted_heap_ops". For the restricted memory, totally there
> are two steps:
> a) memory_alloc: Allocate the buffer in kernel;
> b) memory_restrict: Restrict/Protect/Secure that buffer.
> The memory_alloc is mandatory while memory_restrict is optinal since it may
>
s/optinal/optional/
> be part of memory_alloc.
>
> Signed-off-by: Yong Wu <yong.wu@...iatek.com>
> ---
> drivers/dma-buf/heaps/restricted_heap.c | 41 ++++++++++++++++++++++++-
> drivers/dma-buf/heaps/restricted_heap.h | 12 ++++++++
> 2 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/heaps/restricted_heap.c b/drivers/dma-buf/heaps/restricted_heap.c
> index fd7c82abd42e..8c266a0f6192 100644
> --- a/drivers/dma-buf/heaps/restricted_heap.c
> +++ b/drivers/dma-buf/heaps/restricted_heap.c
> @@ -12,10 +12,44 @@
>
> #include "restricted_heap.h"
>
> +static int
> +restricted_heap_memory_allocate(struct restricted_heap *heap, struct restricted_buffer *buf)
> +{
> + const struct restricted_heap_ops *ops = heap->ops;
> + int ret;
> +
> + ret = ops->memory_alloc(heap, buf);
> + if (ret)
> + return ret;
> +
> + if (ops->memory_restrict) {
> + ret = ops->memory_restrict(heap, buf);
> + if (ret)
> + goto memory_free;
> + }
> + return 0;
> +
> +memory_free:
> + ops->memory_free(heap, buf);
> + return ret;
> +}
> +
> +static void
> +restricted_heap_memory_free(struct restricted_heap *heap, struct restricted_buffer *buf)
> +{
> + const struct restricted_heap_ops *ops = heap->ops;
> +
> + if (ops->memory_unrestrict)
> + ops->memory_unrestrict(heap, buf);
> +
> + ops->memory_free(heap, buf);
> +}
> +
> static struct dma_buf *
> restricted_heap_allocate(struct dma_heap *heap, unsigned long size,
> unsigned long fd_flags, unsigned long heap_flags)
> {
> + struct restricted_heap *restricted_heap = dma_heap_get_drvdata(heap);
> struct restricted_buffer *restricted_buf;
> DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> struct dma_buf *dmabuf;
> @@ -28,6 +62,9 @@ restricted_heap_allocate(struct dma_heap *heap, unsigned long size,
> restricted_buf->size = ALIGN(size, PAGE_SIZE);
> restricted_buf->heap = heap;
>
> + ret = restricted_heap_memory_allocate(restricted_heap, restricted_buf);
>
Can we guarantee that "restricted_heap" here isn't NULL (i.e., heap->priv). If
not perhaps we should consider adding a check for NULL in the
restricted_heap_memory_allocate() function?
> + if (ret)
> + goto err_free_buf;
> exp_info.exp_name = dma_heap_get_name(heap);
> exp_info.size = restricted_buf->size;
> exp_info.flags = fd_flags;
> @@ -36,11 +73,13 @@ restricted_heap_allocate(struct dma_heap *heap, unsigned long size,
> dmabuf = dma_buf_export(&exp_info);
> if (IS_ERR(dmabuf)) {
> ret = PTR_ERR(dmabuf);
> - goto err_free_buf;
> + goto err_free_restricted_mem;
> }
>
> return dmabuf;
>
> +err_free_restricted_mem:
> + restricted_heap_memory_free(restricted_heap, restricted_buf);
> err_free_buf:
> kfree(restricted_buf);
> return ERR_PTR(ret);
> diff --git a/drivers/dma-buf/heaps/restricted_heap.h b/drivers/dma-buf/heaps/restricted_heap.h
> index 443028f6ba3b..ddeaf9805708 100644
> --- a/drivers/dma-buf/heaps/restricted_heap.h
> +++ b/drivers/dma-buf/heaps/restricted_heap.h
> @@ -15,6 +15,18 @@ struct restricted_buffer {
>
> struct restricted_heap {
> const char *name;
> +
> + const struct restricted_heap_ops *ops;
> +};
> +
> +struct restricted_heap_ops {
>
This have the same name as used for the dma_heap_ops in the file
restricted_heap.c, this might be a little bit confusing, or?
> + int (*heap_init)(struct restricted_heap *heap);
> +
> + int (*memory_alloc)(struct restricted_heap *heap, struct restricted_buffer *buf);
> + void (*memory_free)(struct restricted_heap *heap, struct restricted_buffer *buf);
> +
> + int (*memory_restrict)(struct restricted_heap *heap, struct restricted_buffer *buf);
> + void (*memory_unrestrict)(struct restricted_heap *heap, struct restricted_buffer *buf);
>
Is the prefix "memory_" superfluous here in these ops?
Also related to a comment on the prior patch. The name here is "heap" for
restricted_heap, but below you use rstrd_heap. It's the same struct, so I would
advise to use the same name to avoid confusion when reading the code. As
mentioned before, I think the name "rheap" would be a good choice.
> };
>
> int restricted_heap_add(struct restricted_heap *rstrd_heap);
> --
> 2.25.1
>
--
// Regards
Joakim
Powered by blists - more mailing lists