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

[Hans de Goede]

Hi,

On 01/20/2014 05:09 PM, Matthew Garrett wrote:
> On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote:
>> Hi,
>> On 01/20/2014 03:18 PM, Matthew Garrett wrote:
>>> -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?
>
> The KMS driver only supports the g200 cores embedded in some server
> chipsets, it doesn't handle real hardware. We've already dropped 3D
> support for those chips, though, so it's arguably not of great
> importance. The only real difference in functionality by dropping -mga
> would be losing multihead support, and I don't think anyone ever made
> that work on the UMS driver without the HAL blob.
>
>>> 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.
>
> The binary drivers don't need iopl(), so the only real question is
> whether they need root for anything else. It may just be permissions on
> device nodes, in which case we can probably just special-case them?

Probably. TBH I'm not that interested in the binary drivers I know the nvidia one
is actually quite decent and it has a lot of users. So I don't want to break them,
but beyond that my interest stops. I assume they are still not exporting any kms
API to userspace, so the helper I've in mind should just launch X as root for them
and then things should just keep working. I know lots of shoulds ...

>
>>> 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.
>
> I don't see it being any harder than the blacklisting of nouveau/radeon
> that's already required.

Well that can be done through a config file, this would require doing a chmod on the Xorg
binary which would need to be redone after every update. This assumes that if we go the
uvesafb route we completely remove the helper to launch Xorg as root. Then again as you've
indicated above they may not need root at all and a couple of udev rules to open the
right /dev/foo nodes to console users might be enough.

>> And then we could simply forget about supporting ums at all I guess.
>
> That would be certainly be a glorious flying-car future.

Yep, I think it is probably more realistic to go for the helper first though. I'm going to
send a mail to xorg-devel to see how crazy people there think it is to turn uvesafb into a
kms driver.

Regards,

Hans