linux-kernel - Re: [PATCH v5 2/9] scatterlist: Add a flag for the restricted memory

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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20240628-cuddly-brave-squid-e1cb22@houat>
Date: Fri, 28 Jun 2024 15:40:22 +0200
From: "mripard@...nel.org" <mripard@...nel.org>
To: Christian König <christian.koenig@....com>
Cc: 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 01:42:27PM GMT, Christian König wrote:
> Am 27.06.24 um 16:40 schrieb mripard@...nel.org:
> > [SNIP]
> > > > > > > > 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.
> > 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).
> 
> Yeah, that's perfectly fine. At least the AMD encryption solution
> works exactly like that as well.

> > So nobody can map that buffer, and the firmware driver is the one who
> > knows that this buffer cannot be accessed by anyone.
> 
> On most hw I know you can actually map that buffer, it's just that the
> CPU sees only garbage in it because you don't have the necessary
> decryption keys around.

So you can always map and access the buffer, but only if you're in the
right "context" the content would be correct?

I think that part is pretty different than what ARM SoCs are doing,
where they would typically prevent any CPU access and fault on access.

> > 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.
> 
> But that's exactly how all other implementations work as far as I know. I
> mean what do you do if the kernel maps the encrypted buffer?
> 
> On AMD we also block userspace and kernel CPU accesses, but that is only
> done to make it easier to find bugs not for correctness.
> 
> And userspace absolutely needs to be aware that a buffer is encrypted, cause
> otherwise it could potentially try to access it with the CPU.

I absolutely agree. I guess our discussion is whether it's something
that should be implicit and understood by applications, or if it should
be explicit and discoverable.

Maxime

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