I would argue 'restricted' is the proper name since that was what was
settled on for the dma-buf code. :) But you are definitely right
that this memory is not encrypted.
On Tue, Apr 16, 2024 at 7:09 AM Nicolas Dufresne wrote:
>
> Hi,
>
> Le mercredi 03 avril 2024 à 18:26 +0800, Shawn Sung a
On Fri, Jan 12, 2024 at 5:13 AM Daniel Vetter wrote:
>
> On Sun, Dec 24, 2023 at 02:29:24AM +0800, Jason-JH.Lin wrote:
> > 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
On Fri, Jan 12, 2024 at 3:51 PM John Stultz wrote:
>
> On Fri, Jan 12, 2024 at 3:27 PM Jeffrey Kardatzke
> wrote:
> > On Fri, Jan 12, 2024 at 2:52 PM John Stultz wrote:
> > > On Fri, Jan 12, 2024 at 1:21 AM Yong Wu wrote:
> > > > diff --git a/drivers/dma-bu
On Fri, Jan 12, 2024 at 2:52 PM John Stultz wrote:
>
> On Fri, Jan 12, 2024 at 1:21 AM 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:
On Mon, Dec 11, 2023 at 2:58 AM Hans Verkuil wrote:
>
> On 06/12/2023 09:15, Yunfei Dong wrote:
> > From: Jeffrey Kardatzke
> >
> > Verfies in the dmabuf implementations that if the secure memory flag is
>
> Verfies -> Verifies
Thanks. Yunfei, change t
On Mon, Dec 11, 2023 at 3:05 AM Hans Verkuil wrote:
>
> On 06/12/2023 09:15, Yunfei Dong wrote:
> > From: Jeffrey Kardatzke
> >
> > Adds documentation for V4L2_MEMORY_FLAG_SECURE.
> >
> > Signed-off-by: Jeffrey Kardatzke
> > Signed-off-by: Yunfei Dong
Yunfei,
Can you please integrate these changes into the patch?
Thanks,
Jeff
On Mon, Dec 11, 2023 at 2:45 AM Hans Verkuil wrote:
>
> Hi Yunfei, Jeffrey,
>
> Some comments below:
>
> On 06/12/2023 09:15, Yunfei Dong wrote:
> > From: Jeffrey Kardatzke
> >
> &g
Any feedback from maintainers on what their preference is? I'm fine
with 'restricted' as well, but the main reason we chose secure was
because of its use in ARM nomenclature and this is more for ARM usage
than x86.
The main difference with similar buffers on AMD/Intel is that with
AMD/Intel the
You should drop this patch completely.
On Sat, Nov 11, 2023 at 3:18 AM Yong Wu wrote:
>
> Add a normal CMA heap which use the standard cma allocate.
>
> Signed-off-by: Yong Wu
> ---
> Hi Vijay and Jaskaran,
>
> For this heap,
> 1) It uses sec_heap_buf_ops currently. I guess we cann't use the
>
Most of the things in this patch should go in the MTK specific
implementation (except for the secure_heap_init changes). Especially
the RESERVEDMEM_OF_DECLARE.
On Sat, Nov 11, 2023 at 3:18 AM Yong Wu wrote:
>
> Create a new MediaTek CMA heap from the CMA reserved buffer.
>
> In this heap, When
May I suggest the following for the device tree binding? (I'm not very
familiar w/ device trees, so apologies for any oversights, but trying
to process the feedback here and help move Mediatek along). This
should align with my other suggestions for having an MTK specific
portion to their secure
On Sat, Nov 11, 2023 at 3:17 AM Yong Wu wrote:
>
> Add TEE service call. In the case of MediaTek, secure memory management is
> located within the TEE. The kernel just needs to tell TEE what size it
> needs and the TEE will return a "security handle" to kernel.
>
> To be consistent with the cma
Everything in this patch set should move into the MTK specific
implementation I suggested in patch 1 (secure_heap_mtk.c)
On Sat, Nov 11, 2023 at 3:17 AM Yong Wu wrote:
>
> The TEE probe later than dma-buf heap, and PROBE_DEDER doesn't work
> here since this is not a platform driver, therefore
On Sat, Nov 11, 2023 at 3:16 AM Yong Wu wrote:
>
> For the secure memory, there are two steps:
> a) Allocate buffers in kernel side;
> b) Secure that buffer.
> Different heaps may have different buffer allocation methods and
> different memory protection methods. Here abstract the memory
>
On Sat, Nov 11, 2023 at 3:16 AM Yong Wu wrote:
>
> Initialize a secure heap. Currently just add a null heap, Prepare for
> the later patches.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/Kconfig | 7 +++
> drivers/dma-buf/heaps/Makefile | 1 +
>
The main goal is for secure video playback, and to also enable other
potential uses of this in the future. The 'secure dma-heap' will be
used to allocate dma_buf objects that reference memory in the secure
world that is inaccessible/unmappable by the non-secure (i.e.
kernel/userspace) world. That
for those regions and then allocations are
performed within the defined region is the preferred strategy.
On Thu, Sep 28, 2023 at 11:54 PM Benjamin Gaignard
wrote:
>
>
> Le 28/09/2023 à 19:48, Jeffrey Kardatzke a écrit :
> > On Thu, Sep 28, 2023 at 1:30 AM Benjamin Gaignard
> > w
for those regions and then allocations are performed within the defined
region is the preferred strategy.
On Thu, Sep 28, 2023 at 11:54 PM Benjamin Gaignard <
benjamin.gaign...@collabora.com> wrote:
>
> Le 28/09/2023 à 19:48, Jeffrey Kardatzke a écrit :
> > On Thu, Sep 28, 2023 a
You can remove the DRIVER_RENDER flag from this patchset. That should
not be upstreamed. The IOCTLs are still needed though because of the
flag for allocating a secure surface that is in the next patch. If
that flag wasn't needed, then dumb buffer allocations could be used
instead.
Thanks,
Jeff
On Thu, Sep 28, 2023 at 1:30 AM Benjamin Gaignard
wrote:
>
>
> Le 27/09/2023 à 20:56, Jeffrey Kardatzke a écrit :
> > On Wed, Sep 27, 2023 at 8:18 AM Benjamin Gaignard
> > wrote:
> >>
> >> Le 27/09/2023 à 15:46, Joakim Bech a écrit :
> >>> On
On Wed, Sep 27, 2023 at 8:18 AM Benjamin Gaignard
wrote:
>
>
> Le 27/09/2023 à 15:46, Joakim Bech a écrit :
> > On Mon, Sep 25, 2023 at 12:49:50PM +, Yong Wu (吴勇) wrote:
> >> On Tue, 2023-09-12 at 11:32 +0200, AngeloGioacchino Del Regno wrote:
> >>> Il 12/09/23 08:17, Yong Wu (吴勇) ha scritto:
On Wed, Sep 27, 2023 at 6:46 AM Joakim Bech wrote:
>
> On Mon, Sep 25, 2023 at 12:49:50PM +, Yong Wu (吴勇) wrote:
> > On Tue, 2023-09-12 at 11:32 +0200, AngeloGioacchino Del Regno wrote:
> > > Il 12/09/23 08:17, Yong Wu (吴勇) ha scritto:
> > > > On Mon, 2023-09-11 at 11:29 +0200,
On Tue, Sep 19, 2023 at 10:26 PM CK Hu (胡俊光) wrote:
>
> Hi, Jason:
>
> On Tue, 2023-09-19 at 11:03 +0800, Jason-JH.Lin wrote:
> > The patch series provides drm driver support for enabling secure
> > video
> > path (SVP) playback on MediaiTek hardware in the Linux kernel.
> >
> > Memory
On Mon, Sep 18, 2023 at 11:33 PM Daniel Stone wrote:
>
> Hi Jason, CK,
>
> On Tue, 19 Sept 2023 at 04:04, Jason-JH.Lin wrote:
> > The patch series provides drm driver support for enabling secure video
> > path (SVP) playback on MediaiTek hardware in the Linux kernel.
> >
> > [...]
> >
> > Memory
On Mon, Sep 18, 2023 at 3:47 AM Yong Wu (吴勇) wrote:
>
> On Tue, 2023-09-12 at 10:53 -0500, Rob Herring wrote:
> >
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> > On Tue, Sep 12, 2023 at 11:13:50AM +0100, Robin Murphy
25 matches
Mail list logo
