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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 5 Aug 2011 18:11:11 -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 Fri, Aug 5, 2011 at 6:06 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 08/05/2011 02:26 PM, Andrew Lutomirski wrote:
>>
>> For a boot time switch, it might be nicer to just switch between the
>> current int 0xcc sequence and the older
>>
>> mov cx, 0x<magic>
>> int 0xcc
>> ret
>>
>> sequence.
>>
>> That way there's a ret in the vsyscall page but no syscall instruction.
>>
>
> Refresh my memory... we have what... six legacy vsyscall entry points?
> We could, hypothetically, burn six interrupt vectors with them.  If we
> get them from the 0x40-0x4f range, then they are harmless standalone REX
> prefixes (and INC/DEC instructions in 32-bit mode.)

Only three.  I have no real objection to burning two more vectors.
0xCD would also be safe.  ISTR that lower numbers like 0x40 might
actually mean something (ISA?).  32-bit semantics are irrelevant
because 32-bit code can't jump to the vsyscall page anyway.

>
> The issue with pin as far as I understand is that it's executing an
> instruction at a different address and expecting it to have identical
> semantics, which is an incorrect assumption for trapping instructions
> (consider doing that for something like SYSENTER!).

Agreed.  I think that no matter what we do we should encourage
userspace apps to stop doing dumb things.

>
> Now, as far as RET is concerned I don't see how it does anything that
> the INT instruction doesn't do already; ANY of the emulated instructions
> have to return to the address on the stack in order to work at all, OR
> they can return to the next address and do RET.

True.  But the emulated vsyscalls will segfault unless the registers
are valid points that they can write to, which makes them a little
harder to use than ret.

(And some day we could have a sysctl to turn off even the emulated syscalls.)

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