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
