Messages in this thread | | | Subject | Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP) | From | Jim Keniston <> | Date | Wed, 20 Jan 2010 12:28:45 -0800 |
| |
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 proposed jmpq *(%rip) .quad next_insn 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?
No.
> > > 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 > instructions.
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.
> > -Andi >
Thanks. Jim
| |