Re: New vsyscall emulation breaks JITs

[Andrew Lutomirski]

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[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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/