mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	musl@lists.openwall.com,
	Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [musl] Re: [PATCH] Make abort() AS-safe (Bug 26275).
Date: Thu, 1 Oct 2020 10:55:34 -0400	[thread overview]
Message-ID: <20201001145533.GO17637@brightrain.aerifal.cx> (raw)
In-Reply-To: <ed7f2026-92e7-a8ba-a2b4-feb43817b2e3@redhat.com>

On Thu, Oct 01, 2020 at 10:49:42AM -0400, Carlos O'Donell wrote:
> On 10/1/20 2:08 AM, Florian Weimer wrote:
> > * Rich Felker:
> > 
> >> Even without fork, execve and posix_spawn can also see the SIGABRT
> >> disposition change made by abort(), passing it on to a process that
> >> should have started with a disposition of SIG_IGN if you hit exactly
> >> the wrong spot in the race.
> > 
> > My feeling is that it's not worth bothering with this kind of leakage.
> > We've had this bug forever in glibc, and no one has complained about
> > it.
> > 
> > Carlos is investigating removal of the abort lock from glibc, I think.
>  
> I am investigating the removal, but I think the replacement solution
> might be needing to have a helper thread carry out specific tasks.

I'm confused what a helper thread could achieve here. The underlying
problem is that the kernel forces CLONE_SIGHAND on threads (EINVAL
without it) so that the disposition can't be changed in a thread-local
manner. Any new thread would have that same issue. It also would not
be something you could reliably create at abort time (especially since
abort is most often used on resource exhaustion and other unexpected
failures).

Rich

  reply	other threads:[~2020-10-01 14:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200927141952.121047-1-carlos@redhat.com>
     [not found] ` <871rinm1fx.fsf@mid.deneb.enyo.de>
     [not found]   ` <20200928234833.GC17637@brightrain.aerifal.cx>
     [not found]     ` <87d025jcn0.fsf@mid.deneb.enyo.de>
     [not found]       ` <20200929144207.GD17637@brightrain.aerifal.cx>
2020-10-01  2:30         ` Rich Felker
2020-10-01  6:08           ` Florian Weimer
2020-10-01 14:39             ` Rich Felker
2020-10-01 15:11               ` Florian Weimer
2020-10-01 15:28                 ` Rich Felker
2020-10-01 14:49             ` Carlos O'Donell
2020-10-01 14:55               ` Rich Felker [this message]
2020-10-10  0:26           ` Rich Felker

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=20201001145533.GO17637@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=carlos@redhat.com \
    --cc=fw@deneb.enyo.de \
    --cc=libc-alpha@sourceware.org \
    --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).