This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86_64 RIP-relative addressing bug


Frank Ch. Eigler wrote:
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.

I proposed this approach before for i386 to avoid having to fix things up. However, the fixup for the i386 were simple enough not to require this approache. For x86_64 things might be complicated enough.


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.

Need a count of the number of probe points (int3) on a page. Only two versions of the page: original and one with int3.


How expensive is it locally changing a page mapping? Would need to do it before and after the single step.

-Will


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]