Message-ID: <BANLkTik1c9BvaoTKTdpTi9MRJYBLsNH4vA@mail.gmail.com>
Date:	Sun, 29 May 2011 23:26:03 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Mikael Pettersson <mikpe@...uu.se>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] x86 vdso updates

On Sun, May 29, 2011 at 2:44 PM, Andrew Lutomirski <luto@....edu> wrote:
> On Sun, May 29, 2011 at 2:06 PM, Mikael Pettersson <mikpe@...uu.se> wrote:
>> Andrew Lutomirski writes:
>>  > On Sun, May 29, 2011 at 12:01 PM, Mikael Pettersson <mikpe@...uu.se> wrote:
>>  > > Andrew Lutomirski writes:
>>  > >  >
>>  > >  > 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.
>>
>> I can relatively easily also consider the original application rIP
>> when decoding and translating these instructions.
>>
>>  >
>>  > --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?
>>
>> Yes, I just need to know how to identify them and what their equivalents are.
>> E.g., an int3 at <known address> becomes syscall rAX=<some constant>.
>>
>> Sounds like this change will be manageable after all.  Thanks.
>
> I'm not entirely sure I like that -- that way if we ever change it
> again we break your stuff again.
>
> Here are two proposals.
>
> 1. Teach your code that call 0xffffffffff600000 means
> gettimeofday(rdi, rsi).  That's guaranteed to never change and will
> keep working even if we start to emulate vsyscalls by marking the page
> not present and trapping the instruction fetch fault.

valgrind might be doing this.  It does not appear to trace directly
into vsyscalls, or at least it doesn't copy the int 0xcc instruction
out of them.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists