From: Hans de Goede <hdegoede@redhat.com>
To: "Maxime Ripard" <mripard@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>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Milan Zamazal" <mzamazal@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: Mon, 6 May 2024 16:01:42 +0200 [thread overview]
Message-ID: <cbe5a743-d8be-4b0e-99c4-e804fbadc099@redhat.com> (raw)
In-Reply-To: <ZjjdUBYYKXJ1EPr5@phenom.ffwll.local>
Hi Sima,
On 5/6/24 3:38 PM, Daniel Vetter wrote:
> On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
>>> Hi dma-buf maintainers, et.al.,
>>>
>>> Various people have been working on making complex/MIPI cameras work OOTB
>>> with mainline Linux kernels and an opensource userspace stack.
>>>
>>> The generic solution adds a software ISP (for Debayering and 3A) to
>>> libcamera. Libcamera's API guarantees that buffers handed to applications
>>> using it are dma-bufs so that these can be passed to e.g. a video encoder.
>>>
>>> In order to meet this API guarantee the libcamera software ISP allocates
>>> dma-bufs from userspace through one of the /dev/dma_heap/* heaps. For
>>> the Fedora COPR repo for the PoC of this:
>>> https://hansdegoede.dreamwidth.org/28153.html
>>
>> For the record, we're also considering using them for ARM KMS devices,
>> so it would be better if the solution wasn't only considering v4l2
>> devices.
>>
>>> I have added a simple udev rule to give physically present users access
>>> to the dma_heap-s:
>>>
>>> KERNEL=="system", SUBSYSTEM=="dma_heap", TAG+="uaccess"
>>>
>>> (and on Rasperry Pi devices any users in the video group get access)
>>>
>>> This was just a quick fix for the PoC. Now that we are ready to move out
>>> of the PoC phase and start actually integrating this into distributions
>>> the question becomes if this is an acceptable solution; or if we need some
>>> other way to deal with this ?
>>>
>>> Specifically the question is if this will have any negative security
>>> implications? I can certainly see this being used to do some sort of
>>> denial of service attack on the system (1). This is especially true for
>>> the cma heap which generally speaking is a limited resource.
>>
>> There's plenty of other ways to exhaust CMA, like allocating too much
>> KMS or v4l2 buffers. I'm not sure we should consider dma-heaps
>> differently than those if it's part of our threat model.
>
> So generally for an arm soc where your display needs cma, your render node
> doesn't. And user applications only have access to the later, while only
> the compositor gets a kms fd through logind. At least in drm aside from
> vc4 there's really no render driver that just gives you access to cma and
> allows you to exhaust that, you need to be a compositor with drm master
> access to the display.
>
> Which means we're mostly protected against bad applications, and that's
> not a threat the "user physically sits in front of the machine accounts
> for", and which giving cma access to everyone would open up. And with
> flathub/snaps/... this is very much an issue.
I agree that bad applications are an issue, but not for the flathub / snaps
case. Flatpacks / snaps run sandboxed and don't have access to a full /dev
so those should not be able to open /dev/dma_heap/* independent of
the ACLs on /dev/dma_heap/*. The plan is for cameras using the
libcamera software ISP to always be accessed through pipewire and
the camera portal, so in this case pipewere is taking the place of
the compositor in your kms vs render node example.
So this reduces the problem to bad apps packaged by regular distributions
and if any of those misbehave the distros should fix that.
So I think that for the denial of service side allowing physical
present users (but not sandboxed apps running as those users) to
access /dev/dma_heap/* should be ok.
My bigger worry is if dma_heap (u)dma-bufs can be abused in other
ways then causing a denial of service.
I guess that the answer there is that causing other security issues
should not be possible ?
Regards,
Hans
next prev parent reply other threads:[~2024-05-06 14:01 UTC|newest]
Thread overview: 52+ 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 [this message]
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-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
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=cbe5a743-d8be-4b0e-99c4-e804fbadc099@redhat.com \
--to=hdegoede@redhat.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=dri-devel@lists.freedesktop.org \
--cc=jstultz@google.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).