linux-kernel - Re: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?

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]

Message-ID: <a3428b0c352c24d43a2d458d41819fbf4b6cce0f.camel@collabora.corp-partner.google.com>
Date: Wed, 15 May 2024 13:43:58 -0400
From: nicolas.dufresne@...labora.corp-partner.google.com
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Maxime Ripard <mripard@...hat.com>, Bryan O'Donoghue
 <bryan.odonoghue@...aro.org>, Dmitry Baryshkov
 <dmitry.baryshkov@...aro.org>,  Hans de Goede <hdegoede@...hat.com>, Sumit
 Semwal <sumit.semwal@...aro.org>, Benjamin Gaignard
 <benjamin.gaignard@...labora.com>, Brian Starkey <Brian.Starkey@....com>, 
 John Stultz <jstultz@...gle.com>, "T.J. Mercier" <tjmercier@...gle.com>,
 Christian König <christian.koenig@....com>, Lennart
 Poettering <mzxreary@...inter.de>,  Robert Mader
 <robert.mader@...labora.com>, Sebastien Bacher
 <sebastien.bacher@...onical.com>, Linux Media Mailing List
 <linux-media@...r.kernel.org>, "dri-devel@...ts.freedesktop.org"
 <dri-devel@...ts.freedesktop.org>,  linaro-mm-sig@...ts.linaro.org, Linux
 Kernel Mailing List <linux-kernel@...r.kernel.org>, Milan Zamazal
 <mzamazal@...hat.com>, Andrey Konovalov <andrey.konovalov.ynk@...il.com>
Subject: Re: Safety of opening up /dev/dma_heap/* to physically present
 users (udev uaccess tag) ?

Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > You'll hit the same limitation as we hit in GStreamer, which is that KMS driver
> > only offer allocation for render buffers and most of them are missing allocators
> > for YUV buffers, even though they can import in these formats. (kms allocators,
> > except dumb, which has other issues, are format aware).
> 
> My experience on Arm platforms is that the KMS drivers offer allocation
> for scanout buffers, not render buffers, and mostly using the dumb
> allocator API. If the KMS device can scan out YUV natively, YUV buffer
> allocation should be supported. Am I missing something here ?

There is two APIs, Dumb is the legacy allocation API, only used by display
drivers indeed, and the API does not include a pixel format or a modifier. The
allocation of YUV buffer has been made through a small hack, 

  bpp = number of bits per component (of luma plane if multiple planes)
  width = width
  height = height * X

Where X will vary, "3 / 2" is used for 420 subsampling, "2" for 422 and "3" for
444. It is far from idea, requires deep knowledge of each formats in the
application and cannot allocate each planes seperatly.

The second is to use the driver specific allocation API. This is then abstracted
by GBM. This allows allocating render buffers with notably modifiers and/or use
cases. But no support for YUV formats or multi-planar formats.

Nicolas