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).