Date: Fri, 28 Jun 2024 15:57:49 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Christian König <christian.koenig@....com>
Cc: "mripard@...nel.org" <mripard@...nel.org>, 
	Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>, "daniel@...ll.ch" <daniel@...ll.ch>, 
	"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>, "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

On Fri, Jun 28, 2024 at 02:34:24PM GMT, Christian König wrote:
> Am 28.06.24 um 13:47 schrieb Thierry Reding:
> > [SNIP]
> > > > 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.
> > > That doesn't work in all cases, unfortunately.
> > > 
> > > If you're doing secure video playback, the firmware is typically in
> > > charge of the frame decryption/decoding, and you'd get dma-buf back that
> > > aren't accessible by the CPU (or at least, not at the execution level
> > > Linux runs with).
> > Can you clarify which firmware you're talking about? Is this secure
> > firmware, or firmware running on the video decoding hardware?
> > 
> > > So nobody can map that buffer, and the firmware driver is the one who
> > > knows that this buffer cannot be accessed by anyone. Putting this on the
> > > userspace to know would be pretty weird, and wouldn't solve the case
> > > where the kernel would try to map it.
> > Doesn't userspace need to know from the start whether it's trying to do
> > secure playback or not? Typically this involves more than just the
> > decoding part. You'd typically set up things like HDCP as part of the
> > process, so userspace probably already does know that the buffers being
> > passed around are protected.
> > 
> > Also, the kernel shouldn't really be mapping these buffers unless
> > explicitly told to. In most cases you also wouldn't want the kernel to
> > map these kinds of buffers, right? Are there any specific cases where
> > you expect the kernel to need to map these?
> > 
> > I've been looking at this on the Tegra side recently and the way it
> > works on these chips is that you basically get an opaque carveout region
> > that has been locked down by secure firmware or early bootloaders, so
> > only certain hardware blocks can access it. We can allocate from that
> > carveout and then pass the buffers around.
> > 
> > It may be possible to use these protected carveout regions exclusively
> > from the DRM/KMS driver and share them with multimedia engines via DMA-
> > BUF, but I've also been looking into perhaps using DMA-BUF heaps to
> > expose the carveout, which would make this a bit more flexible and allow
> > either userspace to allocate the buffers or have multiple kernel drivers
> > share the carveout via the DMA-BUF heap. Though the latter would require
> > that there be in-kernel APIs for heaps, so not too sure about that yet.
> 
> Yeah as far as I can see that would be a perfectly valid use case for
> DMA-Buf heaps.
> 
> One question here: How does the HDCP setup work on Tegra? From your comment
> I guess you pass most of the information through userspace as well.

Well, we don't currently support HDCP at all. I do have proof-of-concept
patches from a long time ago and, yes, judging by that we'd need to
control all of this from userspace. The way I imagine that this would
work is that userspace needs to first set the "Content Protection" and
"HDCP Content Type" properties and wait for the state change. Once that
has happened it can go and allocate the protected memory and start
decoding into it and then scan out from these buffers.

> Or is there any info inside the DMA-buf for this? In other words would you
> also need to know if a buffer is then allocated from this special carveout?

I don't think so. It's possible to scan out an unprotected buffer with
HDCP enabled. It may also be possible to scan out a protected buffer
even if HDCP wasn't enabled, though you would obviously want to prevent
that somehow. Not sure if there's a common way to do this, but I guess
in end-user devices you'd need a fully trusted boot chain to do that in
a compliant way.

It's been a long time since I looked at this, but I seem to recall that
at the time all software that could do DRM-protected playback on Linux
was proprietary for reasons like these.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists