xf86EnableIO & ExtendedEnabled vs. the input thread

[Adam Jackson]

On Wed, 2019-01-23 at 14:22 -0800, Alan Coopersmith wrote:

> I've confirmed with our kernel folks that the syscall we call from
> xf86EnableIO() on Solaris has always only set the IOPL for the calling
> thread and not other threads.  They believe the primary difference between
> Linux & Solaris is that when a new thread is spawned, it inherits the IOPL
> on Linux, but on Solaris we reset the IOPL for the new thread instead of
> inheriting it.

Makes sense to me.

> While we could update this in the kernel, that won't solve the problem for
> people on older kernels, or one of the OpenSolaris off-shoots (and wearing
> my security hat, I actually prefer the least-privilege method of not having
> all new threads inherit the iopl from the main thread).

Agreed.

> But I have to ask if anyone remembers why we keep track of this flag in
> userspace at all - it's not just Solaris, but it seems to have been
> cargo-culted to most platforms:
> 
> hw/xfree86/os-support/bsd/arm_video.c
> hw/xfree86/os-support/bsd/i386_video.c
> hw/xfree86/os-support/linux/lnx_video.c
> hw/xfree86/os-support/solaris/sun_vid.c
> 
> Is there any reason we just don't drop ExtendedEnabled altogether and
> just always pass the calls through to the kernel?   That'd leave us
> still needing to call xf86EnableIO() in the input thread on Solaris,
> unlike Linux, but that's more sensible than forcing a DisableIO()
> first just to reset the ExtendedEnabled state.

I can't think of a good reason to track ExtendedEnabled, no. All of the
implementations look like they're idempotent (though I had to read the
weird Linux ppc thing twice to be sure). The ExtendedEnabled logic
itself seems to predate XFree86 4.0, which is back far enough in the
dark ages that I don't think we'd ever find a useful changelog for its
motivation. I say nuke it.

- ajax