linux-kernel - Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

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]

Message-ID: <5349CCE3.3000003@zytor.com>
Date:	Sat, 12 Apr 2014 16:31:47 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alexander van Heukelum <heukelum@...tmail.fm>,
	Andy Lutomirski <luto@...capital.net>,
	Brian Gerst <brgerst@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>, stable@...per.es
Subject: Re: [tip:x86/urgent] x86-64, modify_ldt: Ban 16-bit segments on 64-bit
 kernels

On 04/12/2014 04:26 PM, Alexander van Heukelum wrote:
>>>
>>> c. Trampoline in kernel space
>>>
>>> A trampoline in kernel space is not feasible since all ring transition
>>> instructions capable of returning to 16-bit mode require the use of the
>>> stack.
> 
> "16 bit mode" -> "a mode with 16-bit stack"

Yes... I believe it is the SS.B bit that is relevant, not CS.B (although
I haven't confirmed that experimentally.)  Not that that helps one iota,
as far as I can tell.

>>> d. Trampoline in user space
>>>
>>> A return to the vdso with values set up in registers r8-r15 would enable
>>> a trampoline in user space.  Unfortunately there is no way
>>> to do a far JMP entirely with register state so this would require
>>> touching user space memory, possibly in an unsafe manner.
> 
> d.2. trampoline in user space via long mode
> 
> Return from the kernel to a user space trampoline via long mode.
> The kernel changes the stack frame just before executing the iret
> instruction. (the CS and RIP slots are set to run the trampoline code,
> where CS is a long mode segment.) The trampoline code in userspace
> is set up to this single instruction: a far jump to the final CS:EIP
> (compatibility mode).

This still requires user space memory that the kernel can write to.
Long mode is actually exactly identical to what I was suggesting above,
except that I would avoid using self-modifying code in favor of just
parameterization using the high registers.

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