[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1437720743.8534.9.camel@inria.fr>
Date: Fri, 24 Jul 2015 08:52:23 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] fix atexit when it is called from an atexit
handler
Am Freitag, den 24.07.2015, 02:16 +0200 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.fr> [2015-07-23 23:51:53 +0200]:
> > Am Donnerstag, den 23.07.2015, 15:58 -0400 schrieb Rich Felker:
> > > On Thu, Jul 23, 2015 at 09:19:13AM +0200, Jens Gustedt wrote:
> > > > would be good if we could restrict the maximal number of successful
> > > > calls to atexit during exit to 32. A calloc-free strategy could be to
> > > > save head to a tmp a the beginning of processing and to provide a
> > > > `struct fl` table on the stack of __funcs_on_exit.
> > >
> > > I'm not sure how this would be better. It would be more predictable,
> > > but could also probably break some excessive but "valid" use (like
> > > a huge chain of ctors getting called from an atexit handler and all
> > > registering dtors).
> >
> > I think this is really excessive and probably very poor design. atexit
> > should not be abused to make an entry into the list on a per-object
> > base.
> >
> > No application should expect to be able to submit more than 32
> > handlers. After that atexit is allowed to fail, so everything more
> > than that is not portable. I don't advocate to keep strictly on the 32
> > bound (as we do for at_quick_exit), but once the process has entered
> > the exit procedure, there should be pressure to get things terminated.
> >
>
> $ printf '
> set breakpoint pending on
> break __cxa_atexit
> commands
> frame 0
> continue
> end
> run
> ' |gdb clang 2>/dev/null |grep '^Breakpoint' |wc -l
> 610
interesting
> i.e. clang registers 610 atexit handlers.
hm, I don't think these are atexit handlers proper. I looked at the
addresses (sort -u | less), most of them are different, so they are probably
direct calls to __cxa_atexit, not to atexit.
> (in case you wonder: gcc registers 2 including do_fini
> of the musl runtime)
>
> i don't find atexit after exit dangerous: it is
> a programmer error if there are a lot of atexit
> calls,
that's what I meant
> not an input dependent dos attack surface.
I am not an expert in these, but AFAIR all function pointers that are
stored in predictable places are attack surfaces.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
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.
