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: RIP-relative addressing bug


[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


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