Re: New vsyscall emulation breaks JITs

[H. Peter Anvin]

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?

> 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.

	-hpa

--
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/