Message-ID: <5739abdb-0234-412a-9f25-49219411bbc6@amd.com>
Date: Thu, 27 Jun 2024 08:57:40 +0200
From: Christian König <christian.koenig@....com>
To: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>,
 "daniel@...ll.ch" <daniel@...ll.ch>
Cc: "quic_vjitta@...cinc.com" <quic_vjitta@...cinc.com>,
 "angelogioacchino.delregno@...labora.com"
 <angelogioacchino.delregno@...labora.com>,
 "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,
 "jkardatzke@...gle.com" <jkardatzke@...gle.com>,
 "krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
 "joakim.bech@...aro.org" <joakim.bech@...aro.org>,
 Youlin Pei (裴友林) <youlin.pei@...iatek.com>,
 "logang@...tatee.com" <logang@...tatee.com>,
 "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
 Kuohong Wang (王國鴻) <kuohong.wang@...iatek.com>,
 Jianjiao Zeng (曾健姣)
 <Jianjiao.Zeng@...iatek.com>, "contact@...rsion.fr" <contact@...rsion.fr>,
 "benjamin.gaignard@...labora.com" <benjamin.gaignard@...labora.com>,
 "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
 "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
 "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
 "willy@...radead.org" <willy@...radead.org>, "pavel@....cz" <pavel@....cz>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "Brian.Starkey@....com" <Brian.Starkey@....com>,
 "robh+dt@...nel.org" <robh+dt@...nel.org>,
 "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "tjmercier@...gle.com" <tjmercier@...gle.com>,
 "jstultz@...gle.com" <jstultz@...gle.com>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "mripard@...nel.org" <mripard@...nel.org>,
 "robin.murphy@....com" <robin.murphy@....com>,
 Yong Wu (吴勇) <Yong.Wu@...iatek.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "ppaalanen@...il.com" <ppaalanen@...il.com>
Subject: Re: [PATCH v5 2/9] scatterlist: Add a flag for the restricted memory

Am 27.06.24 um 05:21 schrieb Jason-JH Lin (林睿祥):
>
> On Wed, 2024-06-26 at 19:56 +0200, Daniel Vetter wrote:
> >   
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> >  On Wed, Jun 26, 2024 at 12:49:02PM +0200, Christian König wrote:
> > > Am 26.06.24 um 10:05 schrieb Jason-JH Lin (林睿祥):
> > > > > > I think I have the same problem as the ECC_FLAG mention in:
> > > > > > > > 
> > https://lore.kernel.org/linux-media/20240515-dma-buf-ecc-heap-v1-0-54cbbd049511@kernel.org/
> > > > > > > > I think it would be better to have the user configurable
> > private
> > > > > > information in dma-buf, so all the drivers who have the same
> > > > > > requirement can get their private information from dma-buf
> > directly
> > > > > > and
> > > > > > no need to change or add the interface.
> > > > > > > > What's your opinion in this point?
> > > > >  > Well of hand I don't see the need for that.
> > > > > > What happens if you get a non-secure buffer imported in your
> > secure
> > > > > device?
> > > > 
> > > > We use the same mediatek-drm driver for secure and non-secure
> > buffer.
> > > > If non-secure buffer imported to mediatek-drm driver, it's go to
> > the
> > > > normal flow with normal hardware settings.
> > > > 
> > > > We use different configurations to make hardware have different
> > > > permission to access the buffer it should access.
> > > > 
> > > > So if we can't get the information of "the buffer is allocated
> > from
> > > > restricted_mtk_cma" when importing the buffer into the driver, we
> > won't
> > > > be able to configure the hardware correctly.
> > > 
> > > Why can't you get this information from userspace?
> > 
> > Same reason amd and i915/xe also pass this around internally in the
> > kernel, it's just that for those gpus the render and kms node are the
> > same
> > driver so this is easy.
> >

The reason I ask is that encryption here looks just like another 
parameter for the buffer, e.g. like format, stride, tilling etc..

So instead of this during buffer import:

mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, "restricted", 10));
mtk_gem->dma_addr = sg_dma_address(sg->sgl);
mtk_gem->size = attach->dmabuf->size;
mtk_gem->sg = sg;

You can trivially say during use hey this buffer is encrypted.

At least that's my 10 mile high view, maybe I'm missing some extensive 
key exchange or something like that.


>   
> > But on arm you have split designs everywhere and dma-buf
> > import/export, so
> > something else is needed. And neither current kms uapi nor
> > protocols/extensions have provisions for this (afaik) because it
> > works on
> > the big gpus, and on android it's just hacked up with backchannels.
> > 
> > So yeah essentially I think we probably need something like this, as
> > much
> > as it sucks. I see it somewhat similar to handling pcip2pdma
> > limitations
> > in the kernel too.
> > 
> > Not sure where/how it should be handled though, and maybe I've missed
> > something around protocols, in which case I guess we should add some
> > secure buffer flags to the ADDFB2 ioctl.
>
> Thanks for your hint, I'll try to add the secure flag to the ADDFB2
> ioctl. If it works, I'll send the patch.

Yeah, exactly what I would suggest as well.

I'm not an expert for that part, but as far as I know we already have 
bunch of device specific tilling flags in there.

Adding an MTK_ENCRYPTED flag should be trivial.

Regards,
Christian.

>
> Regards,
> Jason-JH.Lin
>
> > -Sima
>
> ************* MEDIATEK Confidentiality Notice ********************
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or otherwise
> exempt from disclosure under applicable laws. It is intended to be
> conveyed only to the designated recipient(s). Any use, dissemination,
> distribution, printing, retaining or copying of this e-mail (including its
> attachments) by unintended recipient(s) is strictly prohibited and may
> be unlawful. If you are not an intended recipient of this e-mail, or believe
> that you have received this e-mail in error, please notify the sender
> immediately (by replying to this e-mail), delete any and all copies of
> this e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!

Powered by blists - more mailing lists