[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 12 Jan 2021 14:04:54 -0800
From: enh <enh@...gle.com>
To: libc-coord@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>
Subject: Re: Future directions for *_r functions
On Tue, Jan 12, 2021 at 12:30 PM Keith Packard <keithp@...thp.com> wrote:
> Florian Weimer <fweimer@...hat.com> writes:
>
> > * Store a pointer in TLS space that points to the global data object on
> > the main thread, and further TLS data on other threads. This is the
> > approach that was used for _res.
>
> This seems like it would avoid use-after-free, but I can't see how you'd
> ever manage to free the storage -- if you can't free it when the thread
> exits, when can you ever prove that it can't be reached by the
> application?
>
> It sounds like there may be intractable issues with fixing this in a way
> that preserves existing ABI consequences.
>
yeah, that's an interesting failure mode i hadn't thought of. but not one
i've seen in practice on Android, and i've seen a lot of buggy apps in my
time :-)
Android up to and including the current release (a) keeps this stuff in the
mmap() region that includes the thread's stack and (b) doesn't reuse thread
stacks, so you'd probably blow up pretty quickly if you did make this
mistake. (which is another thing to worry about if we do start
reusing thread stacks, which might happen this year. even if it does,
though, that's only likely to happen for apps, meaning toybox or whatever
wouldn't be affected. [not that toybox uses threads, but ykwim.])
> --
> -keith
>
Content of type "text/html" skipped
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.
