Re: mmiotrace bug: recursive probe hit

From: Avi Kivity
Date: Sat Apr 05 2008 - 03:37:27 EST


Pekka Paalanen wrote:
On Sun, 30 Mar 2008 20:26:08 +0300
Pekka Paalanen <pq@xxxxxx> wrote:

C) Vegard mentioned something about per-cpu page tables for kmemcheck.
This would be the ultimate solution, because it would solve two problems:
- recursive probe hits
- missed events due to another cpu disarming the page for single stepping
Would it be possible to have a single temporary per-cpu pte?

I understood kmemcheck has similar issues. Of course, one could force the
system down to a single running CPU, but that feels nasty.

One more idea:


The catch is the instruction emulation. I see KVM has some emulation code,
but I cannot understand it without a deep study that would take me weeks.
Is that general enough to be used, or could it be generalized?
Mmiotrace, apart from executing the instruction with a modified address,
would need to extract the type of IO memory access, width and the data
read/written. And since it is dealing with IO memory, the emulation
should be very careful to access the hardware exactly like the original
instruction would have.

Maybe also kmemcheck could use this approach, since the current approach
is very much like in mmiotrace: #pf, show page, single step, #db trap,
hide page.

Are there other x86(_64) instruction emulation facilities in the kernel
I might use?

Or, if the emulation cannot be used, what would it take to make at least
instruction decoding general enough so that mmiotrace could use that instead
of its own decoding?

I fear modifying KVM emulation code is a too heavy job for me personally.

It should not be too difficult to modify x86_emulate.c to do everything through a function vector. However there is a simpler (for you) solution: run the driver-to-be-reverse-engineered in a kvm guest, and modify kvm userspace to log accesses to mmio regions. This requires the not-yet-merged pci passthrough support. You can reverse engineer Windows drivers with this as well.

This won't work for kmemcheck smp though.

--
Any sufficiently difficult bug is indistinguishable from a feature.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/