linux-kernel - Re: [PATCH v6,04/24] v4l: add documentation for restricted memory flag

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: Wed, 12 Jun 2024 15:43:58 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Tomasz Figa <tfiga@...omium.org>, Laurent Pinchart
	 <laurent.pinchart@...asonboard.com>
Cc: Yunfei Dong <yunfei.dong@...iatek.com>, Jeffrey Kardatzke
 <jkardatzke@...gle.com>, Nícolas "F . R . A . Prado"
 <nfraprado@...labora.com>, Nathan Hebert <nhebert@...omium.org>, Hans
 Verkuil <hverkuil-cisco@...all.nl>, AngeloGioacchino Del Regno
 <angelogioacchino.delregno@...labora.com>, Benjamin Gaignard
 <benjamin.gaignard@...labora.com>, Sebastian Fricke
 <sebastian.fricke@...labora.com>, Mauro Carvalho Chehab
 <mchehab@...nel.org>,  Marek Szyprowski <m.szyprowski@...sung.com>, Chen-Yu
 Tsai <wenst@...omium.org>, Yong Wu <yong.wu@...iatek.com>,  Hsin-Yi Wang
 <hsinyi@...omium.org>, Fritz Koenig <frkoenig@...omium.org>, Daniel Vetter
 <daniel@...ll.ch>,  Steve Cho <stevecho@...omium.org>, Sumit Semwal
 <sumit.semwal@...aro.org>, Brian Starkey <Brian.Starkey@....com>, John
 Stultz <jstultz@...gle.com>, "T . J . Mercier" <tjmercier@...gle.com>,
 Christian König <christian.koenig@....com>, Matthias
 Brugger <matthias.bgg@...il.com>,  linux-media@...r.kernel.org,
 dri-devel@...ts.freedesktop.org,  linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,  linux-mediatek@...ts.infradead.org, 
 Project_Global_Chrome_Upstream_Group@...iatek.com
Subject: Re: [PATCH v6,04/24] v4l: add documentation for restricted memory
 flag

Hi,

Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > Why is this flag needed ? Given that the usage model requires the V4L2
> > device to be a dma buf importer, why would userspace set the
> > V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag and pass a non-restricted
> > buffer to the device ?
> 
> Given that the flag is specified at REQBUF / CREATE_BUFS time, it's
> actually useful to tell the driver the queue is operating in restricted
> (aka secure) mode.
> 
> I suppose we could handle that at the time of a first QBUF, but that
> would make the driver initialization and validation quite a bit of pain.
> So I'd say that the design being proposed here makes things simpler and
> more clear, even if it doesn't add any extra functionality.

There is few more reasons I notice in previous series (haven't read the latest):

- The driver needs to communicate through the OPTEE rather then SCP and some
communication are needed just to figure-out things like supported profile/level
resolutions etc.
- The driver needs to allocate auxiliary buffers in secure heap too, allocation
at runtime are not the best

Note that the discussion around this flag already took place in the very first
iteration of the serie, it was originally using a CID and that was a proposed
replacement from Hans.

regards,
Nicolas