linux-kernel - Re: [RFC]: shmem fd for non-DMA buffer sharing cross drivers

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] [day] [month] [year] [list]

Message-ID: <CAPj87rPQzRUmLAnu09wm8K6Skjb6KTGwL63b4DXPuwdsYXzbSw@mail.gmail.com>
Date:   Fri, 25 Aug 2023 13:20:09 +0100
From:   Daniel Stone <daniel@...ishbar.org>
To:     Hsia-Jun Li <Randy.Li@...aptics.com>
Cc:     Pekka Paalanen <ppaalanen@...il.com>, daniels@...labora.com,
        ayaka <ayaka@...lik.info>, hughd@...gle.com,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Tomasz Figa <tfiga@...omium.org>, linux-mm@...ck.org,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        akpm@...ux-foundation.org, Nicolas Dufresne <nicolas@...fresne.ca>,
        Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: [RFC]: shmem fd for non-DMA buffer sharing cross drivers

Hi,

On Fri, 25 Aug 2023 at 08:56, Hsia-Jun Li <Randy.Li@...aptics.com> wrote:
> On 8/25/23 15:40, Pekka Paalanen wrote:
> > if userspace cannot access things like an image's HDR metadata, then it
> > will be impossible for userspace to program KMS to have the correct
> > color pipeline, or to send intended HDR metadata to a video sink.
> >
> > You cannot leave userspace out of HDR metadata handling, because quite
> > probably the V4L2 buffer is not the only thing on screen. That means
> > there must composition of multiple sources with different image
> > properties and metadata, which means it is no longer obvious what HDR
> > metadata should be sent to the video sink.
> >
> > Even if it is a TV-like application rather than a windowed desktop, you
> > will still have other contents to composite: OSD (volume indicators,
> > channels indicators, program guide, ...), sub-titles, channel logos,
> > notifications... These components ideally should not change their
> > appearance arbitrarily with the main program content and metadata
> > changes. Either the metadata sent to the video sink is kept static and
> > the main program adapted on the fly, or main program metadata is sent
> > to the video sink and the additional content is adapted on the fly.
> >
> > There is only one set of HDR metadata and one composited image that can
> > be sent to a video sink, so both must be chosen and produced correctly
> > at the source side. This cannot be done automatically inside KMS kernel
> > drivers.
>
> There may be some misunderstanding.
> Let suppose this HDR data is in a vendor specific format.
> Both upstream(decoder) and downstream(DRM) hardware devices are coming
> from the same vendor.
> Then we just need to delivery the reference to this metadata buffer from
> the upstream to downstream, both of drivers know how to handle it.
>
> Despite the userspace, we just need to extend a wayland protocol that
> making wayland compositor know how to receive the reference to the
> metadata and set it to the DRM plane.
>
> If you want a common HDR formats for all HDR variants(HDR10+, DV), I am
> not against it. But it won't make the userspace be able to fill the HDR
> metadata even the HDR data comes from the bitstream(likes SEI). We must
> consider the case of Secure Video Path(Digital Right), the bitstream is
> not accessible from (REE) userspace nor linux kernel, the downstream
> must take what the upstream feed.

To summarise from IRC, so it's properly documented: the community will
not accept this.

The mechanism (shmem, dmabuf, copy_from_user, whatever) is _not_ the
problem. The problem is the concept.

There have been incredibly extensive discussions on this list about
colour management and HDR, summarised in documentation in the DRM
repository, as well as three talks at the last XDC. This design is the
result of discussion between many community participants - including
hardware vendors - who have all come up with a design which
prioritises transparency and explicit operation.

What you are suggesting is exactly the opposite of this. A design in
which opaque magic blobs are passed around and the kernel does unknown
things based on the contents of those blobs, contradicts this design.
(This is different to compression, where even if the format is
proprietary, the effect is well-understood - for the current
compression mechanisms, it is a lossless transform.)

The old Android Display Framework (ADF) was based around the same
design with blobs of opaque driver-specific data, where generic code -
either in the kernel or in userspace - could not understand the effect
of these blobs. This design was rejected, and we made a clear choice
to follow the DRM design principles instead.

Upstream will not accept any design which hides magic away. 'GKI is
hard', 'other vendors won't let us', etc, are not good enough reasons
to change our mind on this fundamental principle.

Cheers,
Daniel