This is the mail archive of the systemtap@sourceware.org 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: uprobes and empty functions


On Mon, 2010-11-01 at 10:42 -0700, Josh Stone wrote:
> On 11/01/2010 10:25 AM, Jim Keniston wrote:
> > On Sat, 2010-10-30 at 11:04 -0400, Frank Ch. Eigler wrote:
> >> I'm more worried that we're finding cases where uprobes is willing to
> >> place a breakpoint, but is not fully up to the job of executing the
> >> breakpointed instruction.  To what extent could we flip over the tests
> >> from "known not to work" to "not known to work" in rejecting
> >> instructions?
> > 
> > With x86, we always tended to err on the side of caution, declining to
> > probe instructions (and instruction prefixes) that we hadn't tested.  At
> > some point, presumably, we decided we could handle rep prefixes, and I
> > know we tested probing ret instructions.  For those of us not following
> > chip-bug workarounds, "rep ret" would seem like a very silly
> > instruction, and it's no surprise that we didn't test it.
> 
> The problem is that we're validating the prefixes separately from the
> actual opcodes, without being sure that every combination works.
> 
> I don't think we need to bother with asking what are "reasonable"
> prefixes on *every* opcode -- in truly illegal cases, the cpu will fault
> and uprobes should properly catch and clean up after.  But on opcodes
> for which we have any kind of manual fixup or emulation, we need to be
> certain that we can handle prefixes as well, or else refuse to probe.

We do post-single-step fixups on almost all instructions -- typically
just redirecting the IP back to the probed instruction stream.  ret is
one of the few instruction types where we figured we DON'T need to do a
fixup.

The difficulty in testing {k,u}probes's handling of every
prefix/instruction combo is that we have to verify that the probed
instruction did "the right thing" -- i.e., what the unprobed instruction
would do.  Realistically, that means testing only instructions in
executables that produce predictable results.  With kprobes, you at
least have a well-defined set of instructions that need to be tested --
i.e., all the instructions in the kernel and modules -- even if you
can't arrange to execute them all.  With uprobes, the set of executables
we have to probe is unbounded.

> 
> I'll try enhancing my patch to restrict this, and post it shortly...
> 
> Josh

Jim




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