[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1245278159-6840-1-git-send-email-heukelum@fastmail.fm>
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