Messages in this thread | | | From | Andrew Lutomirski <> | Date | Tue, 9 Aug 2011 13:05:07 -0400 | Subject | Re: New vsyscall emulation breaks JITs |
| |
On Tue, Aug 9, 2011 at 12:57 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 08/09/2011 10:22 AM, Andrew Lutomirski wrote: >> >> 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. >> > > How much worse is a ret instruction over the INT instructions that > modifies very little of the register state and then rets?
I'm far from an expert in exploit writing, but I suspect it's sometimes an additional challenge to make sure that esi and edi are valid pointers before jumping into the vsyscall. That's why I added the code that turns EFAULT into SIGSEGV.
> >> 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.) > > Since pin is going to have to be fixed anyway to run on 3.x, it seems > reasonable to me that they can just fix their vsyscall handling at the > same time. > > Now, the multimodal patch seems reasonable, too. > > I think to some extent there are no actually good solutions here, just > varying degrees of bad. Being able to completely disable vsyscall > without having to recompile seems attractive, though.
Agreed.
I have a rather minimal vm that actually works with vsyscall=none. If you like that patch, I can send it on top of the patch it depends on. I could also try to keep it from wasting one page of memory for the unused image by playing some initdata games or otherwise freeing whichever page isn't selected.
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |