From: Alexander van Heukelum <heukelum@fastmail.fm>
To: LKML <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Andi Kleen <andi@firstfloor.org>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Stas Sergeev <stsp@aknet.ru>, Tejun Heo <tj@kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Alexander van Heukelum <heukelum@fastmail.fm>
Subject: [PATCH 0/3] x86: fix return from kernel to userspace with 16-bit stack
Date: Thu, 18 Jun 2009 00:35:56 +0200 [thread overview]
Message-ID: <1245278159-6840-1-git-send-email-heukelum@fastmail.fm> (raw)
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
next reply other threads:[~2009-06-17 22:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-17 22:35 Alexander van Heukelum [this message]
2009-06-17 22:35 ` [PATCH 1/3] i386: fix return to 16-bit stack from NMI handler Alexander van Heukelum
2009-06-17 22:35 ` [PATCH 2/3] i386: fix/simplify espfix stack switching, move it into assembly Alexander van Heukelum
2009-06-17 22:35 ` [PATCH 3/3] x86: de-assembler-ize asm/desc.h Alexander van Heukelum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1245278159-6840-1-git-send-email-heukelum@fastmail.fm \
--to=heukelum@fastmail.fm \
--cc=andi@firstfloor.org \
--cc=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=stsp@aknet.ru \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®