Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
From: Jim Keniston
Date: Wed Jan 20 2010 - 15:29:14 EST
On Wed, 2010-01-20 at 20:58 +0100, Andi Kleen wrote:
> > Re: rewriting instructions that use rip-relative addressing. We do that
> > now. See handle_riprel_insn() in patch #2. (As far as we can tell, it
> > works, but we'd appreciate your review of it.)
> Yes, but how do you get within 2GB of it?
I'm not sure what you're asking.
To jump between the probed instruction stream and the XOL area, I've
next_insn is a 64-bit address, which presumably allows you to jump to
anywhere in the address space.
To read/write the memory addressed by a rip-relative instruction, we
convert the rip-relative addressing to indirect addressing through a
64-bit scratch register (whose saved value we restore before returning
to the probed instruction stream).
> Add lots of holes
> in the address space?
> > The instruction decoder is used only during instruction analysis, while
> > registering the probe -- i.e., in kernel space.
> Registering the user probe? That means if there's a buffer overflow
> in there it would be exploitable.
Certainly a poorly written probe handler would be a problem. Could you
explain further what you mean? Are you talking about a buffer overflow
in the probed program? in the probe handler? in uprobes?
> > >
> > > In general the trend has been also to make traps faster in the CPU, make
> > > sure you're not optimizing for some old CPU here.
> > I won't argue with that. What Avi seems to be proposing buys us a
> > speedup, but at the cost of increased complexity -- among other things,
> > splitting the instrumentation code between user space (in the "XOL" area
> > -- which would then be used for much more than XOL instruction slots)
> You can't have a single XOL area, at least not if you want to support
> shared libraries on 64bit & rip relative.
I disagree. See above.
> > and kernel space. The splitting would presumably be handled by
> > higher-level code -- SystemTap, perf, or whatever. It's a neat idea,
> > but it seems like a v2 kind of feature.
> I'm not sure it can even work, unless you severly limited the allowed
I'm not sure it can work, either. But I still believe that we've
addressed the known issues wrt the big x86_64 address space.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/