Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Feb 2021 11:15:25 -0500
From: Rich Felker <dalias@...c.org>
To: Dominic Chen <d.c.ddcc@...il.com>
Cc: Carlos O'Donell <carlos@...hat.com>, musl@...ts.openwall.com,
	fweimer@...hat.com
Subject: Re: Incorrect thread TID caching

On Wed, Feb 03, 2021 at 11:22:18PM -0500, Dominic Chen wrote:
> 
> > On Feb 3, 2021, at 10:28 PM, Carlos O'Donell <carlos@...hat.com> wrote:
> > 
> > As Rich said for musl, this is not ABI for glibc either.
> > 
> > I'm not sure why you need to reset the TID cache. In glibc we have
> > containerized tests and we do not need to change internals of the 
> > runtime e.g. unshare (CLONE_NEWUSER, CLONE_NEWPID, CLONE_NEWNS);
> > (see glibc/support/test-container.c).
> 
> 
> Thanks for the advice; sounds like I should just modify my local
> musl to call gettid directly in raise().

No, as noted earlier in this thread we should fix clone() to be like
_Fork() at least in the case where it's not doing things that are
inherently unsafe (CLONE_VM etc.) -- as long as you're making a new
process with normal process semantics, the child should be able to
safely call any AS-safe function in libc, or any function in libc at
all if the parent is not multi-threaded.

The possibility of changing raise() is just for the sake of vfork()
and is independent of the issue here.

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.