[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Oct 2020 10:55:34 -0400
From: Rich Felker <dalias@...c.org>
To: Carlos O'Donell <carlos@...hat.com>
Cc: Florian Weimer <fw@...eb.enyo.de>, musl@...ts.openwall.com,
Carlos O'Donell via Libc-alpha <libc-alpha@...rceware.org>
Subject: Re: Re: [PATCH] Make abort() AS-safe (Bug 26275).
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
