RFC: what to do with ums when the X server is not suid root ?

Hans de Goede hdegoede at redhat.com
Tue Jan 21 08:28:46 UTC 2014


On 01/20/2014 07:19 PM, Andrew Lutomirski wrote:
> On Mon, Jan 20, 2014 at 7:48 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>> On 01/20/2014 03:18 PM, Matthew Garrett wrote:
>>> On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote:
>>>> So now it is time to start looking into some of the corner cases, or
>>>> rather at
>>>> the elephant in the room. What about non-kms drivers. We still have the
>>>> vesa
>>>> driver around as most prominent example, and this is useful for some
>>>> oddball
>>>> cards and for cards which are too new.
>>> -mga is probably also still relevant in some small number of cases.
>> Don't we've a kms driver for those? Or you mean for mga cards not supported
>> by
>> the kms driver?
>>> We can probably kill -cirrus. That would leave -openchrome, which I think
>>> is probably only really relevant for OLPC? What's the situation with the
>>> binary nvidia and amd drivers?
>> Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK
>> those
>> are not compatible with kms, so the helper for other ums drivers would just
>> do
>> the right thing there since there would be no kms capable card to be found
>> in /dev.
>>>> I would like to not break the vesa driver, while still killing the suid
>>>> bit on
>>>> the X server.
>>> It's probably worth considering whether porting uvesafb to kms would be
>>> worthwhile, and then just using -modesetting.
>> Yes that is something I was thinking about too, that would be an interesting
>> approach,
>> it would make it somewhat harder for people to use binary drivers, but not
>> impossible.
> Does uvesafb actually work?  I submitted a patch to the uvesafb kernel
> driver a few months back, and not only is the upstream link [1][2] to
> the v86d helper dead, but no one on the dri-devel list answered my
> request to see if anyone had a copy.  Fedora does not appear to
> package a copy (at least yum whatprovides '*/v86d' doesn't come up
> with anything).  This means that I got a patch into upstream drm and
> that it's quite possible that no one (or maybe a grand total of one
> person) has ever tested.
> Or do you mean the older pre-uvesafb driver?
> [1] http://dev.gentoo.org/~spock/projects/uvesafb
> [2] http://lxr.free-electrons.com/source/Documentation/fb/uvesafb.txt

Thanks for this info. It does indeed some not that widely used / tested atm.
But if we change it to a kms driver an ship it by default that would certainly

As for v86d, if I google for just "v86d" the first hit is:

And that still has a link to a tarbal with sources.



More information about the devel mailing list