Xorg-6.9.0 crashes under DRI

[business_kid]

I seem to have Xorg-6.9.0 compiled on a hardened linux from scratch box. This distro has pax, grsecurity, arc4random, & ssp patching, and you compile everything on the box. DRI has the assembler patched out (see bug 4197 on freedesktop.org)

Now glxinfo tells me I have dri.

glxgears would run while I had no dri and gave me 335 fps. Now that I have dri modules in the kernel, (for a radeon card) glxgears gets a swift knee in the privates from the kernel, and anything else using dri does also. Here's the log

Jan 30 04:27:21 genius kernel: PAX: execution attempt in: <anonymous mapping>, 0349c000-034bc000 0349c000
Jan 30 04:27:21 genius kernel: PAX: terminating task: /usr/X11R6/bin/glxgears(glxgears):16889, uid/euid: 0/0, PC: 0349c400, SP: b196c3ec
Jan 30 04:27:21 genius kernel: PAX: bytes at PC: 55 56 33 c9 8b 6c 24 10 3b e9 0f 84 64 00 00 00 8b 44 24 14
Jan 30 04:27:21 genius kernel: PAX: bytes at SP-4: b196c448 03359eb4 1619c688 00000052 a2a1b000 03359cc0 031e8188 03408844 00000002 a2a1b000 1619c688 00000000 16255e08 16254940 1ca6c8cc 00000000 00000000 0327f33e 03453120 00000004 00010000
Jan 30 04:27:21 genius kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/X11R6/bin/glxgears[glxgears:16889] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:23761] uid/euid:0/0 gid/egid:0/0

It seems both Pax and grsec jumped on it. This is all my fault of course jajvascript:emoticon(':oops:'). But where did I go wrong?

[business_kid]

Murphy's Law applies. I finally discovered paxctl. My bad.

/hangs head in shame and quietly exits

[Dwokfur]

I seem to have Xorg-6.9.0 compiled on a hardened linux from scratch box. This distro has pax, grsecurity, arc4random, & ssp patching, and you compile everything on the box. DRI has the assembler patched out (see bug 4197 on freedesktop.org)

Now glxinfo tells me I have dri.

glxgears would run while I had no dri and gave me 335 fps. Now that I have dri modules in the kernel, (for a radeon card) glxgears gets a swift knee in the privates from the kernel, and anything else using dri does also. Here's the log

Jan 30 04:27:21 genius kernel: PAX: execution attempt in: <anonymous mapping>, 0349c000-034bc000 0349c000
Jan 30 04:27:21 genius kernel: PAX: terminating task: /usr/X11R6/bin/glxgears(glxgears):16889, uid/euid: 0/0, PC: 0349c400, SP: b196c3ec
Jan 30 04:27:21 genius kernel: PAX: bytes at PC: 55 56 33 c9 8b 6c 24 10 3b e9 0f 84 64 00 00 00 8b 44 24 14
Jan 30 04:27:21 genius kernel: PAX: bytes at SP-4: b196c448 03359eb4 1619c688 00000052 a2a1b000 03359cc0 031e8188 03408844 00000002 a2a1b000 1619c688 00000000 16255e08 16254940 1ca6c8cc 00000000 00000000 0327f33e 03453120 00000004 00010000
Jan 30 04:27:21 genius kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/X11R6/bin/glxgears[glxgears:16889] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:23761] uid/euid:0/0 gid/egid:0/0

It seems both Pax and grsec jumped on it. This is all my fault of course jajvascript:emoticon(':oops:'). But where did I go wrong?

I'm using Gentoo Hardened. Although it's more determined compared to Hardened LFS, but it still possible to compile everything from source.

On Hardened Gentoo with PaX/Grsecurity enabled, the Hardened Gentoo Xorg guide mentions, that it is required to use the dlloader mechanism for loading modules instead of the regular elfloader. Guess what, the vendor provided ati and nv modules can't cooperate with this stuff, so Hardened fans should stuck with Xorg's radeon and nv. (I use radeon.) I don't have time to dig myself into these issues (the time constrains are the cause, that I chose Hardened Gentoo instead of Hardened LFS), but activating the dlloader is achieved by including

Code: Select all

#define MakeDllModules YES

in your config. All this is achieved by a specific "USE flag" on Hardened Gentoo. I also haven't give try to Xorg 6.9 yet: it seems, that this "flag" has been moved in v6.9/7.0 on Gentoo - I don't know if the Hardened guys could spend some time on tampering with the new versions or not...

My point is, that if you haven't deal with dlloader yet, than you should look into it and spend some time on.

Regards,
Dw.

[business_kid]

I got going through X-6.9.0 with dlloader. Apparentlly you are stuck with it if you want X.
The price was to meddle with the linking. Throughout X, LD is defined as gcc -nostdlib -m32
So gcc is actually linking. I got going by altering the gcc specs file (/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs) and removing the magic that converted -nonow to -z now. So X was linked with -nonow, and that, apparently is what this version requires.

It also appears to me that freedesktop.org projects are not hugely interested in hardened systems, and until a developer on a hardened system joins them, then it's work for whoever goes around it.

The bottom line is that I have dri on Xorg-6.9.0 in a hardened lfs and stellarium looks cool.
As the principal place that hardened systems have in this world is 'always online' servers, I frankly don't see why too many people will bother, as anyone who ran X on an always online server would at the very least have questions to answer from his superiors. Spped is not an issue I can worry about with the radeon 7000. They were more or less given away in breakfast cereal boxes in the end