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.


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


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