linux-kernel - Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

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: <CAKb7UviAoSh6F1v9kCThayVwnWKKi+w1KDLTHHGsLeS95o+Pjg@mail.gmail.com>
Date:   Tue, 18 Apr 2017 01:04:02 -0400
From:   Ilia Mirkin <imirkin@...m.mit.edu>
To:     Michel Dänzer <michel@...nzer.net>
Cc:     Pekka Paalanen <ppaalanen@...il.com>,
        Daniel Vetter <daniel.vetter@...el.com>,
        amd-gfx@...ts.freedesktop.org, Gerd Hoffmann <kraxel@...hat.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in
 line with reality.

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer <michel@...nzer.net> wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin <imirkin@...m.mit.edu> wrote:
>>>> However, I totally agree with Alex that someone with a BE machine
>>>> should review the whole stack before we could be confident with anything.
>>>
>>> Here's what I'm confident about: xf86-video-nouveau worked just fine
>>> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
>>> off because ... well ... uninorth). fbcon/fbdev accel worked,
>>> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
>>> worked after I fixed up mesa and nv30 driver items in version ... 11.1
>>> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
>>> Jackson in the name of making llvmpipe work on BE, declaring all other
>>> drivers broken, with various fixes by Michel Dänzer to get it back to
>>> working over the years.
>>>
>>> Anyone "fixing" the stack has to maintain that level of functioning
>>> through their various fixing.
>>>
>>> I will double-check that the above still works with the latest
>>> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
>>> weekend). If there are any patches you'd like me to test, now's the
>>> time to ask -- getting the box up and running is the hard part,
>>> booting up an extra kernel -- easy.
>>
>> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
>> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
>> module (which is included in that kernel), updated X to 1.19.2 and
>> mesa to 17.0.3. Everything works fine. Specifically:
>>
>> fbcon on top of fbdev provided by nouveau -- colors are fine
>> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
>> DRI2 -- colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
>> colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
>> -- colors are fine
>> xterm on top of xf86-video-nouveau -- colors are fine
>> xterm on top of xf86-video-modesetting -- colors are fine
>>
>> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
>> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
>> to lacking NPOT and a handful of other things).
>>
>> The modetest utility did have trouble with AR24 and I'm pretty sure
>> the XR24 pattern was off too. However I wouldn't be surprised if the
>> modetest utility itself had endian issues in the pattern generation
>> logic. (Seems to be the case, based on a quick glance at the
>> tests/util/format.c logic and how it's used in pattern.c.)
>>
>> So in short, I think the current definitions of format are fine.
>
> I agree with Pekka that it's not that simple. What you've established is
> that things look fine after going through several layers of abstraction.
> It's possible that multiple bugs in those layers cancel each other out;
> in particular, it's quite likely that the code dealing with DRM formats
> is treating them as using native endianness (one possible giveaway for
> that is using shifts for (un)packing colour components).

Quite true that this proves nothing. However one should note that
fbcon -> fbdev works, and both mesa hw driver and softpipe driver
work, in addition to regular DDX accel. Which means that the bugs, if
they exist, are pretty consistent amongst each other, spanning
multiple layers, all agreeing as to what the proper bugginess is. One
could go so far as to declare it to be a feature.

It does show is that things generally work today in at least some, if
not many, setups, and one can't go around breaking them willy nilly.

  -ilia