All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Michal Simek <monstr@monstr.eu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: sigaltstack fun (was Re: new execve/kernel_thread design)
Date: Sun, 18 Nov 2012 05:45:10 +0000	[thread overview]
Message-ID: <20121118054510.GE16916@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAHTX3d+Ou3_4tGqwyWFfNMSumPw2770_nhV_cTQa89k7+sxdHw@mail.gmail.com>

On Fri, Nov 16, 2012 at 08:59:25AM +0100, Michal Simek wrote:
> Do you have set of tests which should run it?
> 
> 
> > 2) your definition of current_pt_regs() is an exact copy of on in
> > include/linux/ptrace.h; why is "microblaze: Define current_pt_regs"
> > needed at all?  IOW, I'd rather added #include <linux/ptrace.h> to
> > arch/microblaze/kernel/process.c instead...
> 
> Agree. Fixed.
> 
> I have updated that branch or I can send you patches if you like.

Pulled; see #arch-microblaze in there (== beginning of your branch).
As for the other things I'd like to see confirmed...  See #for-michal;
4 commits in there had been hanging around for a long time and if
you are OK with those, I'd like to see them gone into mainline,
by whichever path you prefer.

Another thing that looks like a bug - consider the following testcase:

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
void handler(int n, siginfo_t *foo, void *bar)
{
	char *signame = n == SIGUSR1 ? "SIGUSR1" : "SIGUSR2";
	stack_t stack;
	sigaltstack(NULL, &stack);
	printf("took %s%s\n", signame,
		stack.ss_flags == SS_ONSTACK ? " on altstack" : "");
	if (n == SIGUSR1)
		raise(SIGUSR2);
	printf("%s done\n", signame);
}

main()
{
	struct sigaction s = {
		.sa_sigaction = handler,
		.sa_flags = SA_ONSTACK | SA_SIGINFO
	};
	stack_t stack = {.ss_sp = malloc(16384), .ss_size = 16384};
	sigaction(SIGUSR2, &s, NULL);
	sigaction(SIGUSR1, &s, NULL);
	sigaltstack(&stack, NULL);
	raise(SIGUSR1);
}

Should print
took SIGUSR1 on altstack
took SIGUSR2 on altstack
SIGUSR2 done
SIGUSR1 done
- we raise SIGUSR1, it's marked onstack, we flip to altstack, raise SIGUSR2
and we are still on altstack, obviously.  Now, think what happens on the
way *out* - rt_sigreturn from the second handler will call do_sigaltstack(),
passing it the saved altstack settings... and the user stack pointer we'll
get once we return to caller.  I.e. something within the altstack.  Which
will give you -EPERM.  Which will have microblaze sys_rt_sigreturn() force-feed
you SIGSEGV, AFAICS.

IOW, there's a reason why rt_sigreturn implementations ignore -EPERM from
do_sigaltstack().  A bad one, but...  FWIW, sigaltstack handling is a mess
right now:
	* every architecture has the sucker done separately, even though
there's very little point doing so; worse yet, they tend to come with
asm wrappers from hell, all for no good reason - we need to get userland
stack pointer and that's done in all kinds of messy ways.
	* biarch ones have compat versions that ought to be mergable as
well.
	* rt_sigreturn instances call do_sigaltstack() and ignore just
about everything; -EFAULT is not ignored, but realistically it's impossible
to hit - you'd need a race with munmap() ripping the stack page from under
you just as you've almost finished with sigreturn.  Accesses on both sides
of that stack_t had been done by that point, so nothing short of such munmap()
would do.  Everything else *is* ignored, or we are screwed.  AFAICS, that's
what microblaze has stepped into.

As far as I can tell, the sane way to deal with that would be to introduce
(mandatory) helper that would give you the current userland stack pointer.
It's almost always either user_stack_pointer(current_pt_regs()) or rdusp().
There are few exceptions - itanic has user_stack_pointer giving the backing
store of register stack instead of desired r12 and several architectures
lack user_stack_pointer() even though the stack pointer is saved in pt_regs
and helper is trivial to add.  That dealt with, we can take sys_sigaltstack()
to kernel/signal.c unconditionally.  And kill the wrappers on almost everything.
The next step is unifying compat variants; AFAICS, that's also not a problem.
Then we need bool restore_altstack(const stack_t __user *) and compat
counterpart - originally with "call do_sigaltstack(), fail if and only if
it has returned -EFAULT", then a saner behaviour ("if we are not asked to
change the current settings, just succeed and to hell with on_sig_stack()
check; any other error case means that sigframe had been deliberately messed
with and deserves a failure").

Linus, do you have any objections to the above?  FWIW, I've a tentative
patchset in that direction (most of it from the last cycle); right now
it + stuff currently in signal.git#for-next is at -3.4KLoC and I hadn't
dealt with the biarch side of things yet...

  reply	other threads:[~2012-11-18  5:45 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16 22:35 new execve/kernel_thread design Al Viro
2012-10-17  5:32 ` Max Filippov
2012-10-17  5:43   ` Al Viro
2012-10-17 14:07 ` Jonas Bonn
2012-10-17 14:27   ` Michal Simek
2012-10-17 14:27     ` Michal Simek
2012-10-17 16:07     ` Al Viro
2012-10-17 16:07       ` Al Viro
2012-10-17 16:19       ` Al Viro
2012-10-17 16:19         ` Al Viro
2012-11-15 16:41         ` Michal Simek
2012-11-15 16:41           ` Michal Simek
2012-11-15 21:55           ` Al Viro
2012-11-15 21:55             ` Al Viro
2012-11-16  7:59             ` Michal Simek
2012-11-18  5:45               ` Al Viro [this message]
2012-11-18 18:45                 ` sigaltstack fun (was Re: new execve/kernel_thread design) Linus Torvalds
2012-11-18 19:03                   ` sigaltstack fun David Miller
2012-11-18 19:59                     ` Al Viro
2012-11-18 20:48                       ` David Miller
2012-11-19  4:55                         ` Greg KH
2012-11-18 21:02                       ` Al Viro
2012-11-18 21:18                         ` David Miller
2012-11-19  1:10                           ` Al Viro
2012-11-19  1:30                             ` David Miller
2012-11-19  2:35                               ` Al Viro
2012-11-19  3:27                                 ` David Miller
2012-11-26  5:10                                   ` Al Viro
2012-11-26  5:15                                     ` Al Viro
2012-12-04  3:03                                       ` David Miller
2012-12-04  2:58                                     ` David Miller
2012-11-21  1:53                   ` sigaltstack fun (was Re: new execve/kernel_thread design) Al Viro
2012-10-19 15:49 ` new execve/kernel_thread design Al Viro
2012-10-19 17:16   ` Luck, Tony
2012-10-19 17:30     ` Al Viro
2012-10-19 18:01       ` Tony Luck
2012-10-19 18:33         ` Al Viro
2012-10-19 20:25 ` [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE Chris Metcalf
2012-10-19 20:25 ` Chris Metcalf
2012-10-19 20:25   ` Chris Metcalf
2012-10-19 21:35   ` Al Viro
2012-10-20 13:06     ` Chris Metcalf
2012-10-20 13:06       ` Chris Metcalf
2012-10-20 15:34       ` Al Viro
2012-10-20 17:16         ` Al Viro
2012-10-23 17:30           ` Chris Metcalf
2012-10-23 17:30             ` Chris Metcalf
2012-10-23 18:41             ` Al Viro
2012-10-23 19:22               ` Chris Metcalf
2012-10-23 19:22                 ` Chris Metcalf
2012-10-23 20:36                 ` Al Viro
2012-10-25 13:31                   ` Chris Metcalf
2012-10-25 13:31                     ` Chris Metcalf
2012-10-25 14:25                     ` Al Viro
2012-10-23 20:47               ` Thomas Gleixner
2012-10-23 20:51                 ` Jeff King
2012-10-23 21:09                   ` Catalin Marinas
2012-10-23 21:22                     ` Jeff King
2012-10-24 11:18                       ` Catalin Marinas
2012-10-23 21:25                   ` Thomas Gleixner
2012-10-23 21:47                     ` Jeff King
2012-10-23 22:06                       ` Marc Gauthier
2012-10-23 22:23                         ` Jeff King
2012-10-24  6:02                           ` Johannes Sixt
2012-10-24  1:02                     ` Linus Torvalds
2012-10-24  1:56                       ` Al Viro
2012-10-24  2:14                         ` Linus Torvalds
2012-10-24  6:02                       ` Ingo Molnar
2012-10-23 17:30           ` [PATCH] arch/tile: eliminate pt_regs trampolines for syscalls Chris Metcalf
2012-10-23 17:30             ` Chris Metcalf
2012-10-22 14:23         ` [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE Catalin Marinas
2012-10-25 16:54 ` new execve/kernel_thread design Richard Kuo
2012-10-26 18:31 ` [update] " Al Viro
2012-10-26 18:31   ` Al Viro
2012-10-27  3:32   ` Al Viro
2012-10-27  3:32     ` Al Viro
2012-10-29  7:53   ` Martin Schwidefsky
2012-10-29  7:53     ` Martin Schwidefsky
2012-10-29 13:25     ` Al Viro
2012-10-29 13:25       ` Al Viro
2012-10-29 14:38       ` Martin Schwidefsky
2012-10-29 14:38         ` Martin Schwidefsky
2012-10-29 14:57         ` Al Viro
2012-10-29 14:57           ` Al Viro
2012-12-07 22:23   ` Al Viro
2012-12-07 22:23     ` Al Viro
2012-12-08  2:40     ` Chris Metcalf
2012-12-08  2:40       ` Chris Metcalf
2012-12-08  2:40       ` Chris Metcalf
2012-12-13  1:54     ` Hirokazu Takata
2012-12-13  1:54       ` Hirokazu Takata

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=20121118054510.GE16916@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --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.