Mailing List Archive

Current state of Xorg, KMS, and iopl/ioperm
Patching the Linux kernel to disable the sys_iopl and sys_ioperm system
calls (e.g., by setting CONFIG_GRKERNSEC_IO=y) used to cause the xserver
to fail to start even with KMS-enabled drivers -- at least in the case
of the in-kernel radeon driver.

I don't know what recent changes are responsible but for whatever
reason, X now works fine without the aforementioned system calls on the
same hardware.

Unfortunately, it doesn't work on another machine using the Intel driver
and same X/kernel versions. It fails with the error: "failed to set
IOPL". Does anyone know why the Intel, but not Radeon driver, might be
failing? I don't have any particular knowledge of the inner-workings of
the graphics stack

A quick search turned up the following on the X mailing list: "Fix
initialization when iopl is forbidden":
http://lists.x.org/archives/xorg-devel/2012-September/033656.html

http://cgit.freedesktop.org/~ajax/xserver/patch/?id=d88fb00d791c2b19cf9dd244276838aba3a6b442

The above patch applies to x11-base/xorg-server-1.13.2 (with a fuzz
factor of 2 but it's good) but I haven't had a chance to test it on the
affected machine. I'll post a followup if it fixes the problem.

Dave
Re: Current state of Xorg, KMS, and iopl/ioperm [ In reply to ]
Hahh, it's a nice one!
Since I'm using radeon KMS, I would happily enable the option.
Any of you aware other software might fail by toggling the option?
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Január 31.(Cs) 00:32 időpontban Dave Armstrong ezt írta:
> Patching the Linux kernel to disable the sys_iopl and sys_ioperm system
> calls (e.g., by setting CONFIG_GRKERNSEC_IO=y) used to cause the xserver
> to fail to start even with KMS-enabled drivers -- at least in the case
> of the in-kernel radeon driver.
>
> I don't know what recent changes are responsible but for whatever
> reason, X now works fine without the aforementioned system calls on the
> same hardware.
>
> Unfortunately, it doesn't work on another machine using the Intel driver
> and same X/kernel versions. It fails with the error: "failed to set
> IOPL". Does anyone know why the Intel, but not Radeon driver, might be
> failing? I don't have any particular knowledge of the inner-workings of
> the graphics stack
>
> A quick search turned up the following on the X mailing list: "Fix
> initialization when iopl is forbidden":
> http://lists.x.org/archives/xorg-devel/2012-September/033656.html
>
> http://cgit.freedesktop.org/~ajax/xserver/patch/?id=d88fb00d791c2b19cf9dd244276838aba3a6b442
>
> The above patch applies to x11-base/xorg-server-1.13.2 (with a fuzz
> factor of 2 but it's good) but I haven't had a chance to test it on the
> affected machine. I'll post a followup if it fixes the problem.
>
> Dave
>
>
Re: Current state of Xorg, KMS, and iopl/ioperm [ In reply to ]
I can confirm, that radeon KMS is running despite enabling this option.
From now on I'll run X radeon KMS driver with this option enabled on two
machines (server and notebook). I report back if something pops up.
Interesting: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2013.Január 31.(Cs) 00:32 időpontban Dave Armstrong ezt írta:
> Patching the Linux kernel to disable the sys_iopl and sys_ioperm system
> calls (e.g., by setting CONFIG_GRKERNSEC_IO=y) used to cause the xserver
> to fail to start even with KMS-enabled drivers -- at least in the case
> of the in-kernel radeon driver.
>
> I don't know what recent changes are responsible but for whatever
> reason, X now works fine without the aforementioned system calls on the
> same hardware.
>
> Unfortunately, it doesn't work on another machine using the Intel driver
> and same X/kernel versions. It fails with the error: "failed to set
> IOPL". Does anyone know why the Intel, but not Radeon driver, might be
> failing? I don't have any particular knowledge of the inner-workings of
> the graphics stack
>
> A quick search turned up the following on the X mailing list: "Fix
> initialization when iopl is forbidden":
> http://lists.x.org/archives/xorg-devel/2012-September/033656.html
>
> http://cgit.freedesktop.org/~ajax/xserver/patch/?id=d88fb00d791c2b19cf9dd244276838aba3a6b442
>
> The above patch applies to x11-base/xorg-server-1.13.2 (with a fuzz
> factor of 2 but it's good) but I haven't had a chance to test it on the
> affected machine. I'll post a followup if it fixes the problem.
>
> Dave
>
>
Re: Current state of Xorg, KMS, and iopl/ioperm [ In reply to ]
On 01/31/13 04:12, "Tóth Attila" wrote:
> I can confirm, that radeon KMS is running despite enabling this option.
> From now on I'll run X radeon KMS driver with this option enabled on two
> machines (server and notebook). I report back if something pops up.
> Interesting: Dw.
>

Glad to hear it. FWIW, I haven't noticed any loss of functionality in
any programs since disabling sys_ioperm/sys_iopl. I now have them
disabled even in non- hardened/gresecurity kernels as well.

The remainder of this message applies to the list as a whole:

I'm happy to report that the patch worked: the Intel integrated graphics
drivers now work with "privileged I/O" disabled as well.

In hopes that others might benefit as well, I filed a bug report at BGO:
https://bugs.gentoo.org/show_bug.cgi?id=456220

From there you can also download the patch as a single file (as opposed
to the 3-part series from mailing list to which I linked in my initial
post). I tested against x11-base/xorg-server-1.13.2.

Instead of failing, my Xorg log now emits the harmless message during
initiation: "xf86EnableIOPorts: failed to set IOPL for I/O (Function not
implemented)"

I don't know whether the Gentoo X maintainers will appreciate the
significance, so feel free to add comments if you think it's worthwhile.
Hopefully the changes will be merged upstream soon.


Dave