Re: x86_64 RIP-relative addressing bug

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


On Mon, Feb 28, 2005 at 01:44:09PM -0800, Jim Keniston wrote:
> [...]
> Probepoints are implemented by replacing the first byte of the probed
> instruction with an int3 instruction.  [...]
> 1.  Call the probepoint's pre_handler function.
> 2.  Single-step the probed instruction.
> [...]
> Step 2 can be accomplished [as follows:]
> a) Replace the int3 instruction with the original opcode,
> single-step the instruction, and then put back the int3.  [...]
> This introduces a small time window during which another CPU (in an
> SMP system) can execute the probed instruction but miss the
> probepoint.

I wonder if there is a different way around this problem, by
exploiting the fact that the kernel is running under virtual
addressing.  Would it be possible to have several versions of those
kernel text pages that have probes on them?  The version installed in
the normal page tables would be one with the int3 sitting on the
target opcode.

When a processor hits the int3, it could jump to the kprobes code for
pre-handling.  The trick would be that for single-stepping, the
processor could somehow switch only its own page tables to point to
the original version of the page (without the int3), then single-step,
execute the post-handler, and finally switch back to the int3 page.
During this process, the other processors would still map the version
of the page that includes the int3!

This would require cooperation of the linux VM system, and would get
tricky if more than one probe sits on the same page, but that doesn't
sound insurmountable.

- FChE

Attachment: pgp00000.pgp
Description: PGP signature