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]

Date:	Tue, 9 Aug 2011 13:05:07 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	"H. Peter Anvin" <hpa@...or.com>
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 Tue, Aug 9, 2011 at 12:57 PM, H. Peter Anvin <hpa@...or.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/