From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-73784-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 73743 invoked by alias); 6 Oct 2016 17:42:38 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 73734 invoked by uid 89); 6 Oct 2016 17:42:37 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=initializing, insists
X-HELO: mail-qk0-f179.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=L3+wvrBCl3mdPxKFwjvtGhwo03XirYDme6+8usXq048=;
        b=YSYIdmZUI9c6e3TsqQTfj9hQhjKxOivNcyNASu9M5wQ/oNHAsd3LDpzrb92Ggdx/fM
         iAT9BCeNM4T6dTWuPbgkv7Bl1X1IpjXxTHH+EtSWs2C6jzknew2pLvaSTgoMWyj91jx6
         FhUVdOGRDBDTsd+OAoVwhi1F3DVbxTetrfHyQEAq4u4+b74VK4XhDKInlz4PbkUKPyy/
         nJ69sO2n9iJnOSMDQfLV9aKL/WpLUju5avpfWGc7gf6wkTW37n+PVsUeNaMz6Mi+9SrH
         0x53EmALguICFvAVELm6q2qdKTVHgIbA+87MtqZ4mBYvI3E/Dw/kwst9lkDKsKEmnQ2S
         XcKQ==
X-Gm-Message-State: AA6/9RlBG8oEpKeDacIX5jUpjIWRrKP5xK9MYw1uq/KUGBMlVJxBWfTwWhZ4lSaXPCpr6jFcOuZmYkhS/0qslw==
X-Received: by 10.55.207.16 with SMTP id e16mr17158844qkj.4.1475775746054;
 Thu, 06 Oct 2016 10:42:26 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20161006172631.GO19318@brightrain.aerifal.cx>
References: <CAP145pj+yVz_7ZF8_dNqZ2NE22A_O5QyT195Gy0TgvKq1j3skw@mail.gmail.com>
 <20161006172631.GO19318@brightrain.aerifal.cx>
From: =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= <robert@swiecki.net>
Date: Thu, 06 Oct 2016 17:42:00 -0000
Message-ID: <CAP145pjLiwhx4P3XJQCBrpg=OBmaHWyHHOkvT82eSJ4s8aFLZQ@mail.gmail.com>
Subject: Re: Caching of PID/TID after fork
To: Rich Felker <dalias@libc.org>
Cc: GLIBC Devel <libc-alpha@sourceware.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2016-10/txt/msg00144.txt.bz2

2016-10-06 19:26 GMT+02:00 Rich Felker <dalias@libc.org>:

>> 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-Aug=
ust/009920.html

--=20
Robert =C5=9Awi=C4=99cki