linux-kernel - Re: [PATCH] drm/fb-helper: Only reject FB changes if FB_MISC_USER

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: <6ac07ce5-44a5-1823-1940-21c8e7bcfc5e@daenzer.net>
Date:   Fri, 17 Mar 2017 17:54:31 +0900
From:   Michel Dänzer <michel@...nzer.net>
To:     Daniel Stone <daniel@...ishbar.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm/fb-helper: Only reject FB changes if
 FB_MISC_USER_EVENT is set

On 16/03/17 07:09 PM, Daniel Stone wrote:
> On 16 March 2017 at 09:55, Michel Dänzer <michel@...nzer.net> wrote:
>> Otherwise this can also prevent modesets e.g. for switching VTs.
>>
>> FB_MISC_USER_EVENT is set when the request originates from userspace,
>> which is what we're interested in here according to the DRM_DEBUG
>> output.
>>
>> Bugzilla: https://bugs.freedesktop.org/99841
>> Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev")
>> Signed-off-by: Michel Dänzer <michel.daenzer@....com>
>> ---
>>
>> I'm not entirely sure why the values can not match for a VT switch. If
>> anybody thinks this just papers over the real issue, please speak up.
> 
> It happens for me in multi-head with different resolutions. A real
> compositor will set native resolutions with separate framebuffers, and
> then fbcon will try to set one buffer for both outputs. This works on
> the output with the larger resolution, but the one with the smaller
> resolution will fail due to [xy]res_virtual (IIRC) being different.

That's more or less the line of thinking that lead me to writing this
patch, based on the assumption that the fb->* values correspond to what
was set by whatever we're VT switching from. However, it occurred to me
that it's an invalid assumption; fb here is always fb_helper's
framebuffer for fbdev. I think Ville is right that the tests are bogus
in the first place.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer