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