lkml.org 
[lkml]   [2010]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
From
Date

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



\
 
 \ /
  Last update: 2010-01-20 21:31    [W:2.946 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site