linux-kernel - Re: sigaltstack breaks swapcontext()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrX+nvBy5JTOsgz-gR9OaT2C7C_Gi-grt_rUJmkXuwX6QQ@mail.gmail.com>
Date:	Wed, 6 Jan 2016 10:05:00 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()

On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@...t.ru> wrote:
> Hello.
>
> swapcontext() can be used with signal handlers,
> it swaps the signal masks together with the other
> parts of the context.
> Unfortunately, linux implements the sigaltstack()
> in a way that makes it impossible to use with
> swapcontext().
> Per the man page, sigaltstack is allowed to return
> EPERM if the process is altering its sigaltstack while
> running on sigaltstack. This is likely needed to
> consistently return oss->ss_flags, that indicates
> whether the process is being on sigaltstack or not.
> Unfortunately, linux takes that permission to return
> EPERM too literally: it returns EPERM even if you
> don't want to change to another sigaltstack, but
> only want to disable sigaltstack with SS_DISABLE.
> To my reading of a man page, this is not a desired
> behaviour. Moreover, you can't use swapcontext()
> without disabling sigaltstack first, or the stack will
> be re-used and overwritten by a subsequent signal.
>

The EPERM thing is probably also to preserve the behavior that nested
SA_ONSTACK signals are supposed to work.  (Of course, the kernel gets
this a bit wrong because it forgets to check ss in addition to sp.
That would be relatively straightforward to fix.)

I don't see anything terribly wrong with allowing SS_DISABLE even if
you're on the alt stack.  You could also add a new flag SS_FORCE that
just overrides the check.

> The work-around from this, is not even trivial: I have
> to use the shm tricks to duplicate the sigaltstack in
> the VA space, and move the stack pointer to another
> mirror before calling sigaltstack. Then I use longjmp()
> to restore the stack pointer. Then I can finally use
> swapcontext(). This is an unpleasant work-around.
>
> The fix on a kernel side looks simple: kernel should
> just use ss_flags to determine whether the sigaltstack
> is active. I can make a patch for that, but the problem
> is that the arch-specific code is not using any helper
> function to check for sigaltstack; instead it just uses
> "if (ss_size)" checks.

Huh?  I'm not sure I understand what you're talking about.  It seems
reasonable to have the invariant that ss_size != 0 if and only if an
alt stack is enabled, and do_sigaltstack seems to enforce that
invariant.

> So the patch will need to update
> all arches... I wonder if maybe someone can fix that
> problem and update the arch-specific code. If not,
> I'll probably need to update only the x86-specific code
> and add an arch-specific define, which is a bit nasty.

Just change do_sigaltstack?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/