linux-kernel - Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM

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: <b0cc178c-5412-fa7a-f45b-1191d3af82f9@shipmail.org>
Date:   Tue, 21 Feb 2017 11:52:28 +0100
From:   Thomas Hellstrom <thomas@...pmail.org>
To:     David Airlie <airlied@...hat.com>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf
 DRM_CONTROL nodes)

On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed testing this but you got to understand that not all
>> developer teams have a multitude of
>> developers (we have on average one for the whole linux graphics driver
>> stack except GL), and the bug
>> doesn't show up for QE on regression testing unless they run
>> gnome-sheel/Wayland which they currently don't, and I guess they've been
>> focused on the fb2 regression.
>>
>> It's no secret that we've been using the control nodes for some time.
>> The CONTROL_ALLOW is present in the
>> driver private ioctls and the commit has been there since 2016.
>>
>> The user-space code has been present in vmware-tools also since that
>> commit and due to the long release cycles of
>> open-vm-tools the open-vm-tools version was just about to be released.
>> It's necessary for non-xorg
> can you send a revert against drm-next? I'm not sure how clean it will be.
>
> there might be an intermediate step.
>
> Then can we port vmtools of this behaviour, not even sure what it is doing.
>
> Dave.

So after a quick investigation of the impact it looks like the daemon
patch was pulled out of the Fedora open-vm-tools update in time. This
limits the impact to within VMware where we can update the daemon code
and rerun the test cycle. I've posted a patch that makes it possible for
us to use render-nodes instead of control nodes.

/Thomas