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: <CAObL_7HL7SwCfXsD3dPesE4cU-nmoMCRVCP6u2Mn8efo7EG5Zg@mail.gmail.com>
Date:	Tue, 9 Aug 2011 11:22:12 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, 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 Tue, Aug 9, 2011 at 11:04 AM, Andi Kleen <andi@...stfloor.org> wrote:
>> Why do we care about pin again?
>
> Binary compatibility is not about someone especially caring.

I'm all for binary compatibility with programs that already worked...

>
>>
>> $ ./pin -t obj-intel64/opcodemix.so -- /bin/ls
>> E:3.0 is not a supported linux release
>
> It works with
>
> echo "2.6.39" > /osrelease
> mount --bind /osrelease /proc/sys/kernel/osrelease
>

...but that's more than a little bit sad.  (For example, my patches
"broke" anything that relied on vsyscall 3, aka enosys().  But that
was already broken for years, so clearly no one cared.)

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.

2. Don't apply my patch and let pin and DynamoRIO break.  Downside:
DynamoRIO actually works in 3.0.

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

4. Put native syscall instructions in the vsyscall page, mark it NX,
and trap and emulate vsyscalls on the instruction fetch fault.  I can
do this with no overhead in the success path of the page fault code,
but it will slow down vsyscall emulation quite a bit and it's
intrusive.  This seems like overkill to fix a single known binary that
doesn't really work anyway.

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