public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bryan Ford <baford@mit.edu>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] x86_64 signal handling for 64-bit apps w/ mixed 32-bit code - trivial fix
Date: Wed, 05 Oct 2005 12:35:41 -0400	[thread overview]
Message-ID: <200510051235.41376.baford@mit.edu> (raw)

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

The following trivial patch fixes a bug in signal handling on x86-64: the 
kernel currently fails to save and restore the CS and SS segment registers on 
user-mode signal handler dispatch/return, which makes it impossible for 
64-bit applications to catch and handle signals properly that occur while 
running 32-bit code fragments in compatibility mode.

The proposed patch doesn't affect any performance-critical paths (e.g., 
syscall or interrupt entry/exit), and merely involves a couple more moves 
to/from user space on signal frame setup and sigreturn.  It also doesn't 
affect the size or shape of the sigcontext at all, since there already was an
(unused) slot for CS, and I've assigned the convenient __pad0 field as a slot 
for SS.  The existing, unused slots for FS and GS remain unused for now, and 
I don't see any urgent need to change that.  The only way this might break an 
existing app is if the app tries to cons up its own signal frame (not 
generated by the kernel) and pass it to sigreturn, but this is presumably a 
no-no anyway.

The patch is against linux-2.6.13.3.
Author: Bryan Ford, baford@mit.edu
No copyright claimed; public domain.

[-- Attachment #2: bar --]
[-- Type: text/x-diff, Size: 1866 bytes --]

diff -ur o13/include/asm-x86_64/sigcontext.h linux-2.6.13.3/include/asm-x86_64/sigcontext.h
--- o13/include/asm-x86_64/sigcontext.h	2005-10-03 19:27:35.000000000 -0400
+++ linux-2.6.13.3/include/asm-x86_64/sigcontext.h	2005-10-05 12:06:59.000000000 -0400
@@ -43,7 +43,7 @@
 	unsigned short cs;
 	unsigned short gs;
 	unsigned short fs;
-	unsigned short __pad0; 
+	unsigned short ss; 
 	unsigned long err;
 	unsigned long trapno;
 	unsigned long oldmask;
diff -ur o13/arch/x86_64/kernel/signal.c linux-2.6.13.3/arch/x86_64/kernel/signal.c
--- o13/arch/x86_64/kernel/signal.c	2005-10-03 19:27:35.000000000 -0400
+++ linux-2.6.13.3/arch/x86_64/kernel/signal.c	2005-10-05 12:13:22.000000000 -0400
@@ -110,6 +110,15 @@
 	COPY(r14);
 	COPY(r15);
 
+	/* Kernel saves and restores only CS and DS segments on signals,
+	 * which are the bare essentials needed to allow mixed 32/64-bit code.
+	 * App's signal handler can save/restore other segments if needed. */
+	unsigned short cs, ss;
+	err |= __get_user(cs, &sc->cs);
+	err |= __get_user(ss, &sc->ss);
+	regs->cs = cs | 3;	/* Force into user mode */
+	regs->ss = ss | 3;
+
 	{
 		unsigned int tmpflags;
 		err |= __get_user(tmpflags, &sc->eflags);
@@ -187,6 +196,8 @@
 {
 	int err = 0;
 
+	err |= __put_user(regs->cs, &sc->cs);
+	err |= __put_user(regs->ss, &sc->ss);
 	err |= __put_user(0, &sc->gs);
 	err |= __put_user(0, &sc->fs);
 
@@ -318,7 +329,15 @@
 
 	regs->rsp = (unsigned long)frame;
 
+	/* Set up segment registers to run signal handlers in 64-bit mode,
+	   even if the handler happens to be interrupting 32-bit code. */
+	regs->cs = __USER_CS;
+	regs->ss = __USER_DS;
+
+	/* This, by contrast, has nothing to do with segment registers -
+	   see include/asm-x86_64/uaccess.h for details. */
 	set_fs(USER_DS);
+
 	regs->eflags &= ~TF_MASK;
 	if (test_thread_flag(TIF_SINGLESTEP))
 		ptrace_notify(SIGTRAP);

             reply	other threads:[~2005-10-05 16:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 16:35 Bryan Ford [this message]
2005-10-05 17:38 ` [PATCH] x86_64 signal handling for 64-bit apps w/ mixed 32-bit code - trivial fix Mika Penttilä
2005-10-06 15:22   ` Bryan Ford
2005-10-06 16:46 ` Andi Kleen
2005-10-07 16:32   ` Bryan Ford

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=200510051235.41376.baford@mit.edu \
    --to=baford@mit.edu \
    --cc=linux-kernel@vger.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