From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9820 invoked by alias); 6 Oct 2016 18:05:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 9787 invoked by uid 89); 6 Oct 2016 18:05:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy= X-HELO: brightrain.aerifal.cx Date: Thu, 06 Oct 2016 18:05:00 -0000 From: Rich Felker To: Robert =?utf-8?B?xZp3acSZY2tp?= Cc: GLIBC Devel Subject: Re: Caching of PID/TID after fork Message-ID: <20161006180514.GP19318@brightrain.aerifal.cx> References: <20161006172631.GO19318@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-10/txt/msg00145.txt.bz2 On Thu, Oct 06, 2016 at 07:42:25PM +0200, Robert Święcki wrote: > 2016-10-06 19:26 GMT+02:00 Rich Felker : > > >> 2. Provide some kind of symbol, which would force for TID/PID to be > >> reloaded in glibc. > > > > There's an easy solution that works with existing versions of glibc > > (and other libcs) with no new symbol or new symbol version dependency: > > call the libc clone() function with a tiny dummy stack and a function > > which does nothing but longjmp out to the caller. > > Thanks Rich, that's an interesting idea. I might use it. > > > Though, IMO, the problem still exist. Some subset of non-trivial > projects which are affected by this behavior: > > AFL - https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html > ("because the library caches the result of getpid() when initializing > - and without a way to make it reconsider, PID-dependent calls such as > abort() or raise() will go astray. There is also a library wrapper for > the clone() call that does update the cached PID - but the wrapper is > unwieldy and insists on messing with the process' stack.") > > LXC/Docker - https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-August/009920.html Why can't they use the approach I just described? Rich