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.