From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Daniel Vetter <daniel@ffwll.ch>
Cc: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Lennart Poettering" <mzxreary@0pointer.de>,
"Robert Mader" <robert.mader@collabora.com>,
"Sebastien Bacher" <sebastien.bacher@canonical.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Milan Zamazal" <mzamazal@redhat.com>,
"Maxime Ripard" <mripard@redhat.com>,
"Andrey Konovalov" <andrey.konovalov.ynk@gmail.com>
Subject: Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
Date: Tue, 07 May 2024 16:07:39 -0400 [thread overview]
Message-ID: <4f59a9d78662831123cc7e560218fa422e1c5eca.camel@collabora.com> (raw)
In-Reply-To: <20240507183613.GB20390@pendragon.ideasonboard.com>
Hi,
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.
regards,
Nicolas
next prev parent reply other threads:[~2024-05-07 20:07 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 11:49 Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ? Hans de Goede
2024-05-06 12:05 ` Maxime Ripard
2024-05-06 12:11 ` Hans de Goede
2024-05-06 13:38 ` Daniel Vetter
2024-05-06 14:01 ` Hans de Goede
2024-05-07 11:15 ` Daniel Vetter
2024-05-08 5:46 ` Daniel Stone
2024-05-08 8:33 ` Daniel Vetter
2024-05-08 8:38 ` Daniel Stone
2024-05-08 15:49 ` Daniel Vetter
2024-05-09 9:23 ` Daniel Stone
2024-05-16 10:18 ` Daniel Vetter
2024-05-13 13:51 ` Simon Ser
2024-05-16 10:13 ` Daniel Vetter
2024-05-16 11:49 ` Christian König
2024-05-07 13:34 ` Dmitry Baryshkov
2024-05-07 18:59 ` Laurent Pinchart
2024-05-22 13:34 ` Maxime Ripard
2024-05-23 9:41 ` Daniel Vetter
2024-05-07 13:32 ` Dmitry Baryshkov
2024-05-07 14:34 ` Hans de Goede
2024-05-07 15:09 ` Dmitry Baryshkov
2024-05-07 15:15 ` Bryan O'Donoghue
2024-05-07 15:19 ` Dmitry Baryshkov
2024-05-07 18:40 ` Laurent Pinchart
2024-05-07 19:59 ` Dmitry Baryshkov
2024-05-07 20:15 ` Laurent Pinchart
2024-05-08 8:39 ` Daniel Vetter
2024-05-08 21:54 ` Laurent Pinchart
2024-05-13 8:39 ` Maxime Ripard
2024-05-07 17:36 ` Daniel Vetter
2024-05-07 18:36 ` Laurent Pinchart
2024-05-07 20:07 ` Nicolas Dufresne [this message]
2024-05-08 8:36 ` Daniel Vetter
2024-05-08 21:51 ` Laurent Pinchart
2024-05-08 21:52 ` Laurent Pinchart
2024-05-13 8:29 ` Maxime Ripard
2024-05-13 8:34 ` Laurent Pinchart
2024-05-13 15:10 ` Nicolas Dufresne
2024-05-14 20:42 ` Laurent Pinchart
2024-05-15 17:43 ` nicolas.dufresne
2024-05-16 11:27 ` Laurent Pinchart
2024-05-16 17:11 ` nicolas.dufresne
2024-05-21 8:43 ` Maxime Ripard
2024-05-21 14:18 ` nicolas.dufresne
2024-05-16 7:00 ` Simon Ser
2024-05-16 11:20 ` Laurent Pinchart
2024-05-22 13:02 ` Nicolas Dufresne
2024-05-13 13:42 ` Nicolas Dufresne
2024-05-13 13:51 ` Maxime Ripard
2024-05-13 15:06 ` Nicolas Dufresne
2024-05-14 20:45 ` Laurent Pinchart
2024-05-14 20:52 ` Nicolas Dufresne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f59a9d78662831123cc7e560218fa422e1c5eca.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=Brian.Starkey@arm.com \
--cc=andrey.konovalov.ynk@gmail.com \
--cc=benjamin.gaignard@collabora.com \
--cc=bryan.odonoghue@linaro.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jstultz@google.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mripard@redhat.com \
--cc=mzamazal@redhat.com \
--cc=mzxreary@0pointer.de \
--cc=robert.mader@collabora.com \
--cc=sebastien.bacher@canonical.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).