Wednesday 26 October 2011

Linux! How Dare you?!

Strange. I had started work on proving the vminfo provider. It
was very close to showing results.

Then I hit a strange problem. One of those "Duh!" moments.

So, to check out the vminfo provider, I need to run dtrace to intercept
the probes. But the kernel kept panicing.

Heres the panic:


[ 458.807224] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)


Didnt make sense. It worked a moment ago. Or so I thought.

So next, lets downgrade our probe. We *know* syscalls work because I had
tried that on getting the Ubuntu 11.10 release and validating on the 3.0 kernel.
Lets try something different:


$ dtrace -n fbt::sys_chdir:


(Given a choice of 250,000 probes to choose, I want one, I *know* exists without
looking up, and one which is executed rarely, preferably, on demand). Yup.
This dies too.

Ok, so revert the code to the last release. Repeat. Panic.

Strange.

Lets try a random.other.kernel (Ubuntu 10.04). No problem.

What?!

Ok, the Linux kernel guys are smart. Very smart. What did they do?

They changed the way a kernel is mapped into memory. Previously, all
kernel pages were pretty much executable (especially .data/.bss). This was
unnecessary and they appear to have fixed this. Dtrace does something slightly
suboptimal - a char[] array is declared for executing the breakpoint
trampolines, but this is a BSS symbol. And the page the structure resides in
is no longer executable.

*That* explains why it suddenly broke on the latest kernels. The fix
is easy: just mark the page as executable. I would like to use the
proper API or GCC __attribute__ specifier, but the API calls are problematic -
some are GPL-only exports; others dont expose the pgprot permissions etc.
The "lets modify the page table directly" approach seems to work.

So, I'll release a new dtrace which fixes this problem (and hopefully
a working vminfo provider too).


Post created by CRiSP v10.0.17a-b6101


No comments:

Post a Comment