mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Ingo Molnar <mingo@kernel.org>, Andi Kleen <andi@firstfloor.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Andy Lutomirski <luto@amacapital.net>
Subject: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs
Date: Thu, 12 Mar 2015 13:57:51 -0700	[thread overview]
Message-ID: <405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org> (raw)
In-Reply-To: <cover.1426193719.git.luto@kernel.org>
In-Reply-To: <cover.1426193719.git.luto@kernel.org>

From: Andy Lutomirski <luto@amacapital.net>

The comment in the signal code says that apps can save/restore other
segments on their own.  It's true that apps can *save* SS on their
own, but there's no way for apps to restore it: SYSCALL effectively
resets SS to __USER_DS, so any value that user code tries to load
into SS gets lost on entry to sigreturn.

This recycles two padding bytes in the segment selector area for SS.

While we're at it, we need a second change to make this useful.  If
the signal we're delivering is caused by a bad SS value, saving that
value isn't enough.  We need to remove that bad value from the regs
before we try to deliver the signal.  Oddly, x32 already got this
right.

I suspect that 64-bit programs that try to run 16-bit code and use
signals will have a lot of trouble without this.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/include/asm/sigcontext.h      |  2 +-
 arch/x86/include/uapi/asm/sigcontext.h |  2 +-
 arch/x86/kernel/signal.c               | 22 +++++++++++++---------
 3 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/sigcontext.h b/arch/x86/include/asm/sigcontext.h
index 9dfce4e0417d..f910cdcb71fd 100644
--- a/arch/x86/include/asm/sigcontext.h
+++ b/arch/x86/include/asm/sigcontext.h
@@ -59,7 +59,7 @@ struct sigcontext {
 	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 --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h
index d8b9f9081e86..076b11fd6fa1 100644
--- a/arch/x86/include/uapi/asm/sigcontext.h
+++ b/arch/x86/include/uapi/asm/sigcontext.h
@@ -179,7 +179,7 @@ struct sigcontext {
 	__u16 cs;
 	__u16 gs;
 	__u16 fs;
-	__u16 __pad0;
+	__u16 ss;
 	__u64 err;
 	__u64 trapno;
 	__u64 oldmask;
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index ed37a768d0fc..9511eb7f17b0 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -94,15 +94,8 @@ int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc,
 		COPY(r15);
 #endif /* CONFIG_X86_64 */
 
-#ifdef CONFIG_X86_32
 		COPY_SEG_CPL3(cs);
 		COPY_SEG_CPL3(ss);
-#else /* !CONFIG_X86_32 */
-		/* Kernel saves and restores only the CS segment register on signals,
-		 * which is the bare minimum needed to allow mixed 32/64-bit code.
-		 * App's signal handler can save/restore other segments if needed. */
-		COPY_SEG_CPL3(cs);
-#endif /* CONFIG_X86_32 */
 
 		get_user_ex(tmpflags, &sc->flags);
 		regs->flags = (regs->flags & ~FIX_EFLAGS) | (tmpflags & FIX_EFLAGS);
@@ -164,6 +157,7 @@ int setup_sigcontext(struct sigcontext __user *sc, void __user *fpstate,
 		put_user_ex(regs->cs, &sc->cs);
 		put_user_ex(0, &sc->gs);
 		put_user_ex(0, &sc->fs);
+		put_user_ex(regs->ss, &sc->ss);
 #endif /* CONFIG_X86_32 */
 
 		put_user_ex(fpstate, &sc->fpstate);
@@ -457,9 +451,19 @@ static int __setup_rt_frame(int sig, struct ksignal *ksig,
 
 	regs->sp = (unsigned long)frame;
 
-	/* Set up the CS register to run signal handlers in 64-bit mode,
-	   even if the handler happens to be interrupting 32-bit code. */
+	/*
+	 * Set up the CS and SS registers to run signal handlers in
+	 * 64-bit mode, even if the handler happens to be interrupting
+	 * 32-bit or 16-bit code.
+	 *
+	 * SS is subtle.  In 64-bit mode, we don't need any particular
+	 * SS descriptor, but we do need SS to be valid.  It's possible
+	 * that the old SS is entirely bogus -- this can happen if the
+	 * signal we're trying to deliver is #GP or #SS caused by a bad
+	 * SS value.
+	 */
 	regs->cs = __USER_CS;
+	regs->ss = __USER_DS;
 
 	return 0;
 }
-- 
2.3.0


  reply	other threads:[~2015-03-12 20:58 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 20:57 [PATCH v3 0/2] x86_64: Sigcontext improvements Andy Lutomirski
2015-03-12 20:57 ` Andy Lutomirski [this message]
2015-03-13 16:13   ` [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs Borislav Petkov
2015-03-16  8:11   ` Ingo Molnar
2015-03-16 12:08   ` [tip:x86/asm] x86/signal/64: " tip-bot for Andy Lutomirski
2015-03-17  8:44   ` tip-bot for Andy Lutomirski
2015-03-18 17:19   ` [PATCH v3 1/2] x86_64,signal: " Andrey Wagin
2015-03-18 17:48     ` Oleg Nesterov
2015-03-18 18:06       ` Andy Lutomirski
2015-03-18 18:17         ` Cyrill Gorcunov
2015-03-18 18:20           ` Andy Lutomirski
2015-03-18 18:45             ` Cyrill Gorcunov
2015-03-18 18:25           ` Oleg Nesterov
2015-03-18 18:32             ` Andy Lutomirski
2015-03-18 19:13             ` Cyrill Gorcunov
2015-03-18 18:13       ` Cyrill Gorcunov
2015-03-18 18:31         ` Oleg Nesterov
2015-03-18 18:50           ` Cyrill Gorcunov
2015-03-18 19:52             ` Andrey Wagin
2015-03-18 20:02               ` Oleg Nesterov
2015-03-18 21:26                 ` Andy Lutomirski
2015-03-18 21:34                   ` Pavel Emelyanov
2015-03-18 22:03                     ` Andy Lutomirski
2015-03-19  7:35                       ` Cyrill Gorcunov
2015-03-19 16:08                         ` Andy Lutomirski
2015-03-19 16:19                           ` Cyrill Gorcunov
2015-03-20 11:43                         ` Denys Vlasenko
2015-03-20 11:56                           ` Cyrill Gorcunov
2015-03-20 12:04                             ` Cyrill Gorcunov
2015-03-20 14:07                               ` Oleg Nesterov
2015-03-20 14:47                                 ` Cyrill Gorcunov
2015-04-10 21:59                                   ` Andy Lutomirski
2015-04-10 22:11                                     ` Cyrill Gorcunov
2015-04-10 22:16                                       ` Andy Lutomirski
2015-04-10 22:20                                         ` Cyrill Gorcunov
2015-03-12 20:57 ` [PATCH v3 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext Andy Lutomirski
2015-03-16 12:08   ` [tip:x86/asm] x86/signal/64: " tip-bot for Andy Lutomirski
2015-03-17  8:44   ` tip-bot for Andy Lutomirski
2015-03-13 15:31 ` [PATCH v3 0/2] x86_64: Sigcontext improvements Oleg Nesterov

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=405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org \
    --to=luto@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@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®