Messages in this thread | | | From | Andrew Lutomirski <> | Date | Tue, 9 Aug 2011 11:22:12 -0400 | Subject | Re: New vsyscall emulation breaks JITs |
| |
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
| |