CONFIG_PAX_MEMORY_UDEREF breaks i915 driver

[ThinkRob]

Hi,

I'm trying to build a hardened kernel for a system of mine, and it
appears that CONFIG_PAX_MEMORY_UDEREF breaks the i915 driver. When
I enable the option, the system boots fine, but upon initialization of
X/gdm, I begin to get corruption and artifacting.

A quick check of dmesg output shows the driver reporting that it has
become wedged/hung -- which certainly makes sense, given the output.

Building the exact same kernel config without CONFIG_PAX_MEMORY_UDEREF
causes the problem to disappear.

Any help debugging this is welcome.

Thanks,
Rob

[ThinkRob]

Just to follow-up, the problem persists 2.6.32.25 and the latest grsecurity patch.

Here's the kernel config from one of my unaffected builds. (The only difference between this and the faulty kernels is CONFIG_PAX_MEMORY_UDEREF.)

Thanks.

[spender]

Do you have any OOPs messages in dmesg? If it's directly accessing userland memory, that should be reported and is something we can fix.

-Brad

[ThinkRob]

I don't believe I saw any OOPSs.

I've just built myself a new package from .32.25 without CONFIG_PAX_MEMORY_UDEREF and have been running that with no issues -- but I can try to build one with the feature enabled and boot it tonight just to double check.

Other than looking for OOPS messages, is there anything else you'd like me to do when I boot the broken config?

Thanks,
Rob

[PaX Team]

Other than looking for OOPS messages, is there anything else you'd like me to do when I boot the broken config?

if there's no oops then it'll be a bit tricky to find out the offending userland access. for our purposes the kernel can make two kinds of memory accesses: one which is meant to access userland (and can potentially cause all kinds of CPU exceptions since the userland address is untrusted) and the rest which is not supposed to access userland at all. UDEREF protects both kinds (on i386), the latter being the easy case where you see an oops if it triggers. now the first kind is trickier because the kernel does expect such accesses to potentially fail and has a mechanism (the extable) to handle those failures, normally that means that the function that makes the bad userland access attempt will return some error code (-EFAULT) instead of success (e.g., number of bytes copied). and then it's up to the call chain higher up to do something with the error, but usually there's no report about them. the problem is how to separate the UDEREF faults from the rest. for an experiment you could add a dump_stack() call into arch/x86/kernel/traps.c:do_general_protection() right after the gp_in_kernel label, just before the call to fixup_exception() and see if you get any reports from that when the i915 driver fails.

[ThinkRob]

for an experiment you could add a dump_stack() call into arch/x86/kernel/traps.c:do_general_protection() right after the gp_in_kernel label, just before the call to fixup_exception() and see if you get any reports from that when the i915 driver fails.

Alright. I should have some time to build a new image later this weekend, so I'll compile a couple of testing kernels and see what I can do.

[spender]

Any updates on this? The current patch works fine with UDEREF and i915 for me.

-Brad

[ThinkRob]

I can try again somtime this week. Should I try the 2.6.32.* series patch or the latest testing?

Cheers,
Rob

[spender]

I had tested 2.6.32, but either should work.

-Brad

[ThinkRob]

Is there a patch for the latest stable kernel (2.6.32.28)?

[spender]

Not yet, I'm working on fixing some other issues before I port forward and release new patches.

-Brad

[ThinkRob]

Ok, no worries. I'll give it a shot as soon as the patch is posted.

[ThinkRob]

I can confirm that 2.6.36.3 patched with grsecurity-2.2.1-2.6.36.3-201101131705.patch does not exhibit this problem.

Do you want me to test with 2.6.32.28 as well?

Thanks,
Rob