All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such
Date: Sat, 28 Apr 2012 04:32:45 +0100	[thread overview]
Message-ID: <20120428033245.GT6871@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20120428024208.GS6871@ZenIV.linux.org.uk>

On Sat, Apr 28, 2012 at 03:42:08AM +0100, Al Viro wrote:
> On Sat, Apr 28, 2012 at 12:15:26AM +0100, Al Viro wrote:
> 
> > I think all such architectures need that check lifted to do_notify_resume()
> > (and the rest needs it killed, of course).  Including x86, by the look
> > of it - we _probably_ can't get there with TIF_NOTIFY_RESUME and
> > !user_mode(regs), but I'm not entirely sure of that.  arm is in about the
> > same situation; alpha, ppc{32,64}, sparc{32,64} and m68k really can't get
> > there like that (they all check it in the asm glue).  mips probably might,
> > unless I'm misreading their ret_from_fork()...  Fun.
> 
> It's actually worse than I thought - we can't just lift that check
> to do_notify_resume() and be done with that.  Suppose do_signal() does
> get called on e.g. i386 or arm with !user_mode(regs).  What'll happen next?
> 
> We have TIF_SIGPENDING set in thread flags - otherwise we wouldn't get
> there at all.  OK, do_signal() doesn't do anything and returns.  So does
> do_notify_resume().  And we are back into the loop in asm glue, rereading
> the thread flags (still unchanged), checking if anything is to be done
> (yes, it is - TIF_SIGPENDING is still set), calling do_notify_resume(),
> ad infinitum.
> 
> Lifting the check into do_notify_resume() will not help at all, obviously.
> 
> AFAICS we can get hit by that.  At least i386, arm and mips have
> ret_from_fork going straight to "return from syscall" path, no checks for
> return to user mode done.  And process created by kernel_thread() will
> go there.  It's a narrow race, but AFAICS it's not impossible to hit -
> guess the PID of kernel thread to be launched, send it a signal and hit
> the moment before it gets to executing the payload.
> 
> It's probably not exploitable unless you are root, since most of the
> threads are spawned either by kthreadd or by khelper, both running as
> root.  OTOH, there might be other places leading to the same fun - e.g.
> kernel_execve() goes through the normal syscall return path almost on
> everything and in case of failure it returns to kernel mode.  Again,
> that one is unlikely to be exploitable (it only happens from root-owned
> threads), but I'm not sure if anything else gets there; IIRC, there had
> been an effort to get rid of issuing syscalls via int/syscall/trap/whatnot,
> but I don't remember how far did it go, especially under arch...

Actually, it looks like on i386 the loop will be broken by checks in
resume_userspace_sig, so the worst thing that might happen would be
a bogus call of tracehook_notify_resume() if it's possible to get there
with TIF_NOTIFY_RESUME for kernel thread.  No such luck on arm, though...
To be honest, I'd rather check for user_mode() before calling
do_notify_resume() and go away to no_work_pending if it's true.  For arm
and i386 that would probably look like this, and I'd really, *really*
like review and comments on that.  amd64 is, AFAICS, careful enough to
avoid hitting do_notify_resume() when returning into the kernel mode -
its implementations of ret_from_fork and kernel_execve take care to avoid
that.

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 82aaf0a..e147619 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -57,6 +57,9 @@ work_pending:
 	 * TIF_SIGPENDING or TIF_NOTIFY_RESUME must've been set if we got here
 	 */
 	mov	r0, sp				@ 'regs'
+	ldr	r2, [sp, #S_PSR]
+	tst	r2, #15
+	be	no_work_pending
 	mov	r2, why				@ 'syscall'
 	tst	r1, #_TIF_SIGPENDING		@ delivering a signal?
 	movne	why, #0				@ prevent further restarts
diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index cd41742..f7b7a1c 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -641,15 +641,6 @@ static void do_signal(struct pt_regs *regs, int syscall)
 	int signr;
 
 	/*
-	 * We want the common case to go fast, which
-	 * is why we may in certain cases get here from
-	 * kernel mode. Just return without doing anything
-	 * if so.
-	 */
-	if (!user_mode(regs))
-		return;
-
-	/*
 	 * If we were from a system call, check for system call restarting...
 	 */
 	if (syscall) {
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 7b784f4..e858462 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -321,7 +321,6 @@ ret_from_exception:
 	preempt_stop(CLBR_ANY)
 ret_from_intr:
 	GET_THREAD_INFO(%ebp)
-resume_userspace_sig:
 #ifdef CONFIG_VM86
 	movl PT_EFLAGS(%esp), %eax	# mix EFLAGS and CS
 	movb PT_CS(%esp), %al
@@ -628,9 +627,13 @@ work_notifysig:				# deal with pending signals and
 					# vm86-space
 	TRACE_IRQS_ON
 	ENABLE_INTERRUPTS(CLBR_NONE)
+	movb PT_CS(%esp), %bl
+	andl $SEGMENT_RPL_MASK, %ebx
+	cmpl $USER_RPL, %ebx
+	jb resume_kernel
 	xorl %edx, %edx
 	call do_notify_resume
-	jmp resume_userspace_sig
+	jmp resume_userspace
 
 	ALIGN
 work_notifysig_v86:
@@ -643,9 +646,13 @@ work_notifysig_v86:
 #endif
 	TRACE_IRQS_ON
 	ENABLE_INTERRUPTS(CLBR_NONE)
+	movb PT_CS(%esp), %bl
+	andl $SEGMENT_RPL_MASK, %ebx
+	cmpl $USER_RPL, %ebx
+	jb resume_kernel
 	xorl %edx, %edx
 	call do_notify_resume
-	jmp resume_userspace_sig
+	jmp resume_userspace
 END(work_pending)
 
 	# perform syscall exit tracing
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 595969f..c4aa7c5 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -738,16 +738,6 @@ static void do_signal(struct pt_regs *regs)
 	siginfo_t info;
 	int signr;
 
-	/*
-	 * We want the common case to go fast, which is why we may in certain
-	 * cases get here from kernel mode. Just return without doing anything
-	 * if so.
-	 * X86_32: vm86 regs switched out by assembly code before reaching
-	 * here, so testing against kernel CS suffices.
-	 */
-	if (!user_mode(regs))
-		return;
-
 	signr = get_signal_to_deliver(&info, &ka, regs, NULL);
 	if (signr > 0) {
 		/* Whee! Actually deliver the signal.  */

  reply	other threads:[~2012-04-28  3:32 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18 13:04 [PULL REQUEST] : ima-appraisal patches Mimi Zohar
2012-04-18 15:02 ` James Morris
2012-04-18 18:07   ` Mimi Zohar
2012-04-18 18:39     ` Al Viro
2012-04-18 20:56       ` Mimi Zohar
2012-04-19 19:57       ` Mimi Zohar
2012-04-20  0:43         ` [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) Al Viro
2012-04-20  2:31           ` Linus Torvalds
2012-04-20  2:31             ` Linus Torvalds
2012-04-20  2:54             ` Al Viro
2012-04-20  2:58               ` Linus Torvalds
2012-04-20  2:58                 ` Linus Torvalds
2012-04-20  8:09                 ` Al Viro
2012-04-20 15:56                   ` Linus Torvalds
2012-04-20 15:56                     ` Linus Torvalds
2012-04-20 16:08                     ` Al Viro
2012-04-20 16:42                       ` Al Viro
2012-04-20 17:21                         ` Linus Torvalds
2012-04-20 17:21                           ` Linus Torvalds
2012-04-20 18:07                           ` Al Viro
2012-04-23 18:01                             ` [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such Al Viro
2012-04-23 18:37                               ` Oleg Nesterov
2012-04-24  7:26                               ` Al Viro
2012-04-25  3:06                                 ` Al Viro
2012-04-25 12:37                                   ` Oleg Nesterov
2012-04-25 12:50                                     ` Al Viro
2012-04-25 13:03                                       ` Oleg Nesterov
2012-04-25 13:32                                         ` Oleg Nesterov
2012-04-25 13:32                                         ` Al Viro
2012-04-25 14:52                                           ` Oleg Nesterov
2012-04-25 15:46                                             ` Oleg Nesterov
2012-04-25 16:10                                               ` Al Viro
2012-04-25 17:02                                                 ` Oleg Nesterov
2012-04-25 17:51                                                   ` Al Viro
2012-04-26  7:15                                                     ` Martin Schwidefsky
2012-04-26  7:25                                                       ` David Miller
2012-04-26 13:52                                                       ` Oleg Nesterov
2012-04-26 14:31                                                         ` Martin Schwidefsky
2012-04-26 13:22                                                     ` Oleg Nesterov
2012-04-26 18:37                                 ` Oleg Nesterov
2012-04-26 23:19                                   ` Al Viro
2012-04-27 17:24                                     ` Oleg Nesterov
2012-04-27 17:54                                       ` Oleg Nesterov
2012-05-02 10:37                                         ` Matt Fleming
2012-05-02 14:14                                           ` Al Viro
2012-04-27 18:45                                       ` Al Viro
2012-04-27 19:14                                         ` Geert Uytterhoeven
2012-04-27 19:34                                           ` Al Viro
2012-04-29 22:51                                             ` Al Viro
2012-04-30  6:39                                               ` Greg Ungerer
2012-04-30  6:39                                                 ` Greg Ungerer
2012-04-27 19:42                                         ` Al Viro
2012-04-27 20:20                                         ` Roland McGrath
2012-04-27 21:12                                           ` Al Viro
2012-04-27 21:27                                             ` Roland McGrath
2012-04-27 23:15                                               ` Al Viro
2012-04-27 23:32                                                 ` Al Viro
2012-04-29  4:12                                                   ` Al Viro
2012-04-30  8:06                                                     ` Martin Schwidefsky
2012-04-27 23:50                                                 ` Al Viro
2012-04-28 18:51                                                   ` [PATCH] arch/tile: avoid calling do_signal() after fork from a kernel thread Chris Metcalf
2012-04-28 18:51                                                     ` Chris Metcalf
2012-04-28 20:55                                                     ` Al Viro
2012-04-28 21:46                                                       ` Chris Metcalf
2012-04-28 21:46                                                         ` Chris Metcalf
2012-04-29  0:55                                                         ` Al Viro
2012-04-28 18:51                                                           ` [PATCH v2] arch/tile: fix up some issues in calling do_work_pending() Chris Metcalf
2012-04-28 18:51                                                             ` Chris Metcalf
2012-04-29  3:49                                                           ` [PATCH] arch/tile: avoid calling do_signal() after fork from a kernel thread Chris Metcalf
2012-04-29  3:49                                                             ` Chris Metcalf
2012-04-28  2:42                                                 ` [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such Al Viro
2012-04-28  3:32                                                   ` Al Viro [this message]
2012-04-28  3:36                                                     ` Al Viro
2012-04-29 16:33                                                     ` Oleg Nesterov
2012-04-29 16:18                                                   ` Oleg Nesterov
2012-04-29 18:05                                                     ` Al Viro
2012-05-01  4:31                                                       ` Al Viro
2012-05-01  5:06                                                         ` Mike Frysinger
2012-05-01  5:52                                                           ` Al Viro
2012-05-02 17:24                                                             ` Al Viro
2012-05-02 18:30                                                       ` Oleg Nesterov
2012-04-29 16:41                                         ` Oleg Nesterov
2012-04-29 18:09                                           ` Al Viro
2012-04-29 18:25                                             ` Oleg Nesterov
2012-04-20  3:15               ` [RFC] situation with fput() locking (was Re: [PULL REQUEST] : ima-appraisal patches) Al Viro
2012-04-20 18:54           ` Hugh Dickins
2012-04-20 19:04             ` Al Viro
2012-04-20 19:18               ` Linus Torvalds
2012-04-20 19:32                 ` Hugh Dickins
2012-04-20 19:58                 ` Al Viro
2012-04-20 21:12                   ` Linus Torvalds
2012-04-20 21:12                     ` Linus Torvalds
2012-04-20 22:13                     ` Al Viro
2012-04-20 22:35                       ` Linus Torvalds
2012-04-20 22:35                         ` Linus Torvalds
2012-04-27  7:35                         ` Kasatkin, Dmitry
2012-04-27 17:34                           ` Al Viro
2012-04-27 18:52                             ` Kasatkin, Dmitry
2012-04-27 18:52                               ` Kasatkin, Dmitry
2012-04-27 19:15                               ` Kasatkin, Dmitry
2012-04-30 14:32                             ` Mimi Zohar
2012-04-30 14:32                               ` Mimi Zohar
2012-05-03  4:23                               ` James Morris
2012-05-03  4:23                                 ` James Morris
2012-04-20 19:37               ` Al Viro

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=20120428033245.GT6871@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.