From: Olaf Flebbe <of@oflebbe.de>
To: musl@lists.openwall.com
Subject: Re: [musl] Revisiting sigaltstack and implementation-internal signals
Date: Mon, 10 Aug 2020 10:15:13 +0200 [thread overview]
Message-ID: <2142D551-13BE-4033-94F7-80A7B2C01890@oflebbe.de> (raw)
In-Reply-To: <a2f155e5-d1e8-f039-65c3-11cffbb0ba3b@dereferenced.org>
[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]
Hi,
I have some problems to follow the discussion here.
It is not about musl to create an alternate stack, it is to *honor* the alternate stack, if the application installed one, for a reason.
I am proposing smthg like
--- /oss/musl-1.2.1/src/thread/synccall.c
+++ /work/musl/src/thread/synccall.c
@@ -45,7 +45,7 @@
{
sigset_t oldmask;
int cs, i, r;
- struct sigaction sa = { .sa_flags = SA_RESTART, .sa_handler = handler };
+ struct sigaction sa = { .sa_flags = SA_RESTART|SA_ONSTACK, .sa_handler = handler };
pthread_t self = __pthread_self(), td;
int count = 0;
This will fix the problem with dynamic stacks, like go implements it.
If the application does not install one, kernel will ignore SA_ONSTACK. (This is even specified by POSIX, since there is no error condition mentioned in man page specifically for this).
Tested with go and a glibc threaded setuid test tst-setuid3.c .
Best,
Olaf
> Am 10.08.2020 um 02:28 schrieb Ariadne Conill <ariadne@dereferenced.org>:
>
> Hello,
>
> On 2020-08-08 18:39, Rich Felker wrote:
>> It's come up again, via Go this time (see
>> https://github.com/golang/go/issues/39857), that it would be nice to
>> have musl use the alternate signal stack for implementation-internal
>> signals. I've previously wanted to do this, but been unclear on (1)
>> whether it's permissible for the implementation to touch the
>> application-provided alternate stack when there is no signal delivered
>> on it (possibly not even any signal handlers installed), and (2)
>> whether we should care about breaking code that swaps off of and back
>> onto the alternate signal stack with swapcontext.
>> In regards to question (1), I believe this language from the
>> specification of sigaltstack is sufficient to resolve it:
>> "The range of addresses starting at ss_sp up to but not including
>> ss_sp+ ss_size is available to the implementation for use as the
>> stack."
>> I read "available to the implementation" as implying that the
>> application can make no assumptions about values previously stored in
>> the memory being retained.
>
> This seems like a reasonable position.
>
>> This still leaves (2) open, as well as whether there are any other
>> reasons why we shouldn't have implementation-internal signals using
>> the alternate stack.
>
> In my opinion, mixing stacks with ucontext calls and sigaltstack is undefined behavior. There is no way to guarantee the safety of such operations, or at least none that I can think of.
>
> So personally, I think if people do that, they are basically asking for problems, and we have no obligation to fix those problems.
>
> Ariadne
[-- Attachment #2: Type: text/html, Size: 6708 bytes --]
next prev parent reply other threads:[~2020-08-10 8:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 0:39 Rich Felker
2020-08-09 7:54 ` Markus Wichmann
2020-08-10 0:06 ` Rich Felker
2020-08-10 16:34 ` Markus Wichmann
2020-08-10 0:10 ` Ariadne Conill
2020-08-10 0:26 ` Rich Felker
2020-08-10 0:28 ` Ariadne Conill
2020-08-10 8:15 ` Olaf Flebbe [this message]
2020-08-10 15:41 ` Szabolcs Nagy
2020-08-10 15:45 ` Olaf Flebbe
2020-08-10 16:24 ` Szabolcs Nagy
2020-08-10 16:27 ` Rich Felker
2020-08-10 16:36 ` Rich Felker
2020-08-10 16:57 ` Olaf Flebbe
2020-08-10 17:00 ` Rich Felker
2020-08-10 17:04 ` Olaf Flebbe
2020-08-10 18:32 ` Rich Felker
2020-08-10 19:29 ` Olaf Flebbe
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=2142D551-13BE-4033-94F7-80A7B2C01890@oflebbe.de \
--to=of@oflebbe.de \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).