Re: New vsyscall emulation breaks JITs
From: Andrew Lutomirski
Date: Tue Aug 09 2011 - 11:22:38 EST
On Tue, Aug 9, 2011 at 11:04 AM, Andi Kleen <andi@xxxxxxxxxxxxxx> 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 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 vsyscall fault (exploit attempt?)
nr: 0 ip:7fdc3a5ce78f cs:33 sp:7fffc2339a88 ax:ffffffffff600000 si:0
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.
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/