From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8F7C82862; Wed, 8 May 2024 21:52:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715205173; cv=none; b=VjyEZcT9m+ptoIvSeZjMLjQotvdaBDEcCowNMJ4MSH1SQDn4/yq2KM4uj/E+Ztnp5bKFqJRAc9ga63BWepO6YmBggR3pymB418lB8+rAIB17Ofb9ROaSwmBKgs67x3nBvJVngRX9EBmvfPLvUlEfD7nFX2Va3fggGmfMCkdpnuA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715205173; c=relaxed/simple; bh=Dxw4QBBH0nAYXVaZlwEHYuCWDqlxanntOuSV3i2WstU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R0n+n89BJwiPRW/CEksiUTMIW0k/lwFAGmptKJfcAac08ZsjmVmFrt2gvjrKdr6qO69nsCH6IcYvSJ3wN5VbxYu/+VS+/g/feJcI+YKKGo/aoajPSV7ZLZC3eym9sK0qfY1KJ1zGa8gP60pm+1tLMlvafXVlYwNuaLYdN51HUtc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=cW5C1t21; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="cW5C1t21" Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi [81.175.209.231]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 4D5DE16D4; Wed, 8 May 2024 23:52:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1715205167; bh=Dxw4QBBH0nAYXVaZlwEHYuCWDqlxanntOuSV3i2WstU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cW5C1t21+DNX+W0Qle3A1H5aeRn5hikYb4VkZ1Sy5FWaJXMaDjUM3pTHPzgHjfpZu x0i+YdJRiuFijAViuVu85CtAj4z7erVcm635jCkHcuosl0/lVkSCl9r9WKxHwSKC50 NnkF1sYJ3PRzdU5uJWd95R+uCGVCwrf8YWTE7QY8= Date: Thu, 9 May 2024 00:52:42 +0300 From: Laurent Pinchart To: Daniel Vetter Cc: Nicolas Dufresne , Bryan O'Donoghue , Dmitry Baryshkov , Hans de Goede , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , Christian =?utf-8?B?S8O2bmln?= , Lennart Poettering , Robert Mader , Sebastien Bacher , Linux Media Mailing List , "dri-devel@lists.freedesktop.org" , linaro-mm-sig@lists.linaro.org, Linux Kernel Mailing List , Milan Zamazal , Maxime Ripard , Andrey Konovalov Subject: Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ? Message-ID: <20240508215242.GB24860@pendragon.ideasonboard.com> References: <3c0c7e7e-1530-411b-b7a4-9f13e0ff1f9e@redhat.com> <20240507183613.GB20390@pendragon.ideasonboard.com> <4f59a9d78662831123cc7e560218fa422e1c5eca.camel@collabora.com> <20240508215106.GA24860@pendragon.ideasonboard.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240508215106.GA24860@pendragon.ideasonboard.com> On Thu, May 09, 2024 at 12:51:08AM +0300, Laurent Pinchart wrote: > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote: > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote: > > > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit : > > > > Shorter term, we have a problem to solve, and the best option we have > > > > found so far is to rely on dma-buf heaps as a backend for the frame > > > > buffer allocatro helper in libcamera for the use case described above. > > > > This won't work in 100% of the cases, clearly. It's a stop-gap measure > > > > until we can do better. > > > > > > Considering the security concerned raised on this thread with dmabuf heap > > > allocation not be restricted by quotas, you'd get what you want quickly with > > > memfd + udmabuf instead (which is accounted already). > > > > > > It was raised that distro don't enable udmabuf, but as stated there by Hans, in > > > any cases distro needs to take action to make the softISP works. This > > > alternative is easy and does not interfere in anyway with your future plan or > > > the libcamera API. You could even have both dmabuf heap (for Raspbian) and the > > > safer memfd+udmabuf for the distro with security concerns. > > > > > > And for the long term plan, we can certainly get closer by fixing that issue > > > with accounting. This issue also applied to v4l2 io-ops, so it would be nice to > > > find common set of helpers to fix these exporters. > > > > Yeah if this is just for softisp, then memfd + udmabuf is also what I was > > about to suggest. Not just as a stopgap, but as the real official thing. > > Long term I still want a centralized memory allocator, at which point > libcamera should stop allocating buffers at all. And to be clear, udmabuf could be fine for the time being. At least as long as we don't find any shortcoming while testing it :-) > > udmabuf does kinda allow you to pin memory, but we can easily fix that by > > adding the right accounting and then either let mlock rlimits or cgroups > > kernel memory limits enforce good behavior. -- Regards, Laurent Pinchart