Re: New vsyscall emulation breaks JITs
From: Andrew Lutomirski
Date: Tue Aug 09 2011 - 13:05:30 EST
On Tue, Aug 9, 2011 at 12:57 PM, H. Peter Anvin <hpa@xxxxxxxxx> 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 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.
> 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.
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.
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/