Re: New vsyscall emulation breaks JITs

[Andrew Lutomirski <luto@mit.edu>]

On Tue, Aug 9, 2011 at 11:04 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> Why do we care about pin again?
>
> Binary compatibility is not about someone especially caring.

I'm all for binary compatibility with programs that already worked...

>
>>
>> $ ./pin -t obj-intel64/opcodemix.so -- /bin/ls
>> E:3.0 is not a supported linux release
>
> It works with
>
> echo "2.6.39" > /osrelease
> mount --bind /osrelease /proc/sys/kernel/osrelease
>

...but that's more than a little bit sad.  (For example, my patches
"broke" anything that relied on vsyscall 3, aka enosys().  But that
was already broken for years, so clearly no one cared.)

In any case, my patch fixes DynamoRIO but not pin.  Pin dies with:

[ 4988.945491] test_vsyscall[4587] emulated vsyscall from bogus
address -- fix your code nr: 0 ip:7fdc3a5ce78f cs:33 sp:7fffc2339a88
ax:ffffffffff600000 si:0 di:400d0a
[ 4988.945497] test_vsyscall[4587] vsyscall fault (exploit attempt?)
nr: 0 ip:7fdc3a5ce78f cs:33 sp:7fffc2339a88 ax:ffffffffff600000 si:0
di:400d0a

and I don't know what's going on.  I suspect that the tracer assumes
that int 0x40 continues execution at the next instruction.

x86 maintainers: I can think of a few choices:

1. Stick a ret instruction in the vsyscall page.  Downside: now
there's an unrestricted ret instruction in the vsyscall page.

2. Don't apply my patch and let pin and DynamoRIO break.  Downside:
DynamoRIO actually works in 3.0.

3. Apply my patch and assume that the number of users that would
benefit from a more complete fix is close to zero, since pin won't
even try to run on 3.0 or 3.1 without gross hacks.  (Pin is prerelease
software and apparently actively maintained by people who make it very
hard for non-users to contact, but I'm trying.)

4. Put native syscall instructions in the vsyscall page, mark it NX,
and trap and emulate vsyscalls on the instruction fetch fault.  I can
do this with no overhead in the success path of the page fault code,
but it will slow down vsyscall emulation quite a bit and it's
intrusive.  This seems like overkill to fix a single known binary that
doesn't really work anyway.

--Andy