Re: [GIT pull] x86 vdso updates

[Andrew Lutomirski]

On Sun, May 29, 2011 at 12:01 PM, Mikael Pettersson <mikpe@xxxxxxxx> wrote:
> Andrew Lutomirski writes:
>  > On Sun, May 29, 2011 at 10:39 AM, Mikael Pettersson <mikpe@xxxxxxxx> wrote:
>  > > Ingo Molnar writes:
>  > >  >
>  > >  > * Andrew Lutomirski <luto@xxxxxxx> wrote:
>  > >  >
>  > >  > > On Fri, May 27, 2011 at 7:36 AM, Andrew Lutomirski <luto@xxxxxxx> wrote:
>  > >  > > > 3. Add int 0xcc and use it from vgettimeofday.  It will SIGSEGV if
>  > >  > > > called from a user address (so it has no risk of ever becoming ABI)
>  > >  > > > and it will do gettimeofday if called from the right address.  (I like
>  > > ...
>  > >  > > Make it a real syscall but with extra constraints.  It would have the
>  > >  > > same calling convention as the syscall instruction, but it would turn
>  > >  > > into SIGKILL if the calling address isn't in the VSYSCALL page
>  > >
>  > > This will make things difficult for user-space dynamic binary instrumentation
>  > > applications, since these normally execute generated code at different
>  > > addresses than the original code.
>  > >
>  > > Is there a safe fallback for this particular vsyscall?
>  >
>  > All of the vsyscalls have vDSO versions that work like any other code.
>
> Easiest would be if we can simply map int $0xcc with rAX==FOO to syscall or
> int 0x80 with rAX==BAR.

Yes and no.

With the code I just posted (and am fixing up now) that will work.
But if we want to replace the entire vsyscall page with three int 0xcc
and 4090 int3 instructions, then we can't look at eax because it won't
contain anything meaningful.

--Andy

>
> We currently don't even know about the vDSO, it's all just user-space code
> to us.
>
>  > Alternatively, if the dynamic instrumentation code knew about
>  > vsyscalls, it could just not instrument addresses in the vsyscall
>  > page.
>
> Not instrumenting code is not an option, unless we can prove that the
> code in question has no relevant side-effects or unexpected control-flow.
> (Where "side-effects" relate both to the integrity of the instrumentation
> engine and the application-specific payload it's attaching to the code.)

Calls to 0xffffffffff600000, 0xffffffffff600400, and
0xffffffffff600800 are syscalls, as an (unfortunate) part of the ABI.

>
>  > What existing applications would get broken?
>
> My concern is ThreadSpotter, but any user-space dynamic binary instrumentation
> engine that instruments down to the raw kernel interface (syscall/sysenter/int
> instructions) would have a problem with syscalls that only work at specific
> addresses.

I'll look.

>
> Anyway, if I can map that vsyscall to a plain proper syscall, then I'm OK.

All three vsyscalls can be replaced with real syscalls without side
effects.  Would it be possible to teach the instrumentation code to
deal with that?

--Andy
--
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/