[I got separate copies of this message from separate sender addresses.
I chose this one to reply to, because the other one was multipart/html.]
I like "Disassemble, Fudge, and Register" approach mentioned by Jim that
is if the probed instruction uses RIP-relative addressing, the user-mode
program finds the next "safe" instruction, prints an appropriate warning,
and passes the safe instruction's address as an insmod option.
This approach keeps most of the complexities outside the kernel without
any modifications to the existing kprobes. This approach does not change
the register kprobes interface aswell.
Its easier to maintain the code which is outside the kernel.
As I said, I think the "disassemble" (detection) component is the most
significant work. If we agree the kernel must do that for robustness, then
that's the most important point to me. Having the kernel interface be that
kprobes says "bzzt, try another address" is potentially an acceptable
compromise. But I really do think that once we've gotten that implemented
satisfactorily, it will not be much more work to do the instruction
adjustment (given a supply of scratch space in the reachable code region).
We needn't agree on that second conclusion to begin with, however.
If we implement the detection code and get happy with its robustness,
then we'll be in a much better position to contemplate the adjustment
issues concretely.
Thanks,
Roland