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@xxxxxxxxxx/
> > > > > > > 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!
