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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Jun 2024 16:23:25 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: "mripard@...nel.org" <mripard@...nel.org>, 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

Hi,

Le jeudi 27 juin 2024 à 16:40 +0200, mripard@...nel.org a écrit :
> > 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).
> 
> 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.

Userspace will be the one calling into the CDM TF-A to get the bitstream buffer
to be decrypted, not the firmware. The encrypted buffers are not using
restricted memory. Userspace is also responsible for calling into the MTK
restricted heap to allocate the destination buffer (on other platform it could
be CMA heaps + TF-A call to restrict the allocated memory, I've seen some
discussions related to this, but its not possible on Mediatek HW).

I think its fair to assume that userspace always know which buffers are
restricted or not in the SVP process.

Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ