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-next>] [day] [month] [year] [list]
Date:	Thu, 18 Jun 2009 00:35:56 +0200
From:	Alexander van Heukelum <heukelum@...tmail.fm>
To:	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andi Kleen <andi@...stfloor.org>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Stas Sergeev <stsp@...et.ru>, Tejun Heo <tj@...nel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Alexander van Heukelum <heukelum@...tmail.fm>
Subject: [PATCH 0/3] x86: fix return from kernel to userspace with 16-bit stack

This patchset was generated against the current mainline-git tree, but
also applies just fine to the tip tree.

Some background...

If a userspace application is interrupted by a trap, interrupt, or nmi, 
the processor saves ss:esp, the flags register and cs:eip and loads a 
new ss:esp from the task segment, modifies the flags and loads cs:eip 
from the interrupt descriptor table. After handling the exception, the 
saved values are restored and the user process continues as if nothing 
happened... With one exception: if the process users a 16-bit stack 
segment (as described in the LDT), the processor only restores the low 
16 bits of esp from the saved value. The upper 16 bits are left equal to 
the upper word of the kernel esp. Only very few applications, like 
dosemu and wine, care, but it leads to those applications crashing with, 
usually, a bus error.

The implemented fix is to change the stack segment and stack pointer in 
a clever way just before returning to the userspace application. The 
espfix segment is a normal 32-bit segment, but with a non-zero base. The 
base of the espfix segment and the high word of the temporary esp are 
changed in unison, such that the temporary stack still points to the 
kernel stack, but the high word of esp is already equal to the high word 
of the saved userspace esp. On return to userspace the iret-instruction 
only loads the low word of esp, but the high word was already set to the 
correct value by changing to the temporary espfix stack. Using the 
espfix stack in C code is however unsafe, so fixups to change back to 
the normal stack before entering C code have to be in place.


The patches...

patch 1/3: i386: fix return to 16-bit stack from NMI handler

This patch adds switching to the espfix stack if the kernel returns to 
userspace from the NMI. Commit 55f327fa9e876758491a82af7491104f1cc3fc4d 
("lockdep: irqtrace subsystem, i386 support") removed this check/fixup 
from the NMI return path.

patch 2/3: i386: fix/simplify espfix stack switching, move it into assembly

A long-standing problem with the computation of the espfix base address 
and the temporary stack segment. The combined result always points to 
the kernel stack, but the high word of the espfix stack pointer was not 
always equal to the high word of the saved userspace stack pointer. This 
patch simplifies the fixup code and fixes it.

patch 3/3: x86: de-assembler-ize asm/desc.h

Cleanup patch, split out form previous versions of patch 2/3. In earlier 
versions I forgot to take into account x86_64 when I did the cleanup. 
This version compiles fine on x86_64.

Patch summary:

 arch/x86/include/asm/desc.h  |   26 -----------------
 arch/x86/kernel/cpu/common.c |    2 +-
 arch/x86/kernel/entry_32.S   |   64 +++++++++++++++++++++++++++--------------
 arch/x86/kernel/head_32.S    |    1 -
 arch/x86/kernel/head_64.S    |    1 -
 5 files changed, 43 insertions(+), 51 deletions(-)

I'm typing this message on an Authentic Sempron 2400+ running the 
patched kernel.

Greetings,
    Alexander
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ