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:	Fri, 05 Aug 2011 15:06:58 -0700
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/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.)

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

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.

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