linux-kernel - Re: DMA-buf and uncached system memory

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: <CAPj87rPYQNkgVEdHECQcHcYe2nCpgF3RYQKk_=wwhvJSxwHXCg@mail.gmail.com>
Date:   Thu, 23 Jun 2022 00:34:58 +0100
From:   Daniel Stone <daniel@...ishbar.org>
To:     Nicolas Dufresne <nicolas@...fresne.ca>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Christian König <christian.koenig@....com>,
        "Sharma, Shashank" <Shashank.Sharma@....com>,
        lkml <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linaro-mm-sig@...ts.linaro.org,
        Sumit Semwal <sumit.semwal@...aro.org>,
        linux-media <linux-media@...r.kernel.org>
Subject: Re: DMA-buf and uncached system memory

Hi Nicolas,

On Wed, 22 Jun 2022 at 20:39, Nicolas Dufresne <nicolas@...fresne.ca> wrote:
> Le mardi 16 février 2021 à 10:25 +0100, Daniel Vetter a écrit :
> > So I think if AMD also guarantees to drop clean cachelines just do the
> > same thing we do right now for intel integrated + discrete amd, but in
> > reserve. It's fragile, but it does work.
>
> Sorry to disrupt, but if you pass V4L2 vmalloc data to Intel display driver, you
> also get nice dirt on the screen. If you have a UVC webcam that produces a pixel
> format compatible with your display, you can reproduce the issue quite easily
> with:
>
>   gst-launch-1.0 v4l2src device=/dev/video0 ! kmssink
>
> p.s. some frame-rate are less likely to exhibit the issue, make sure you create
> movement to see it.

Right, this is because the UVC data in a vmalloc() area is not
necessarily flushed from the CPU cache, and the importer expects it
will be.

> The only solution I could think of (not implemented) was to detect in the
> attach() call what the importers can do (with dev->coherent_dma_mask if I
> recall), and otherwise flush the cache immediately and start flushing the cache
> from now on signalling it for DQBUF (in vb2 workqueue or dqbuf ioctl, I don't
> have an idea yet). I bet this idea is inapplicable to were you have fences, we
> don't have that in v4l2.
>
> This idea was hinted by Robert Becket (now in CC), but perhaps I picked it up
> wrong, explaining it wrong, etc. I'm no expert, just noticed there wasn't really
> a good plan for that, so one needs to make one up. I'm not aware oh an importer
> could know how the memory was allocated by the exporter, and worst, how an
> importer could figure-out that the export is going to produce buffer with hot
> CPU cache (UVC driver does memcpy from USB chunks of variable size to produce a
> fixed size image).

This is exactly what Christian was saying above.

Cheers,
Daniel