linux-kernel - Re: New vsyscall emulation breaks JITs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E416716.1040904@zytor.com>
Date:	Tue, 09 Aug 2011 11:57:58 -0500
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andrew Lutomirski <luto@....edu>
CC:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	lueckintel@...oo.com, kimwooyoung@...il.com
Subject: Re: New vsyscall emulation breaks JITs

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