From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8354 invoked by alias); 6 Oct 2016 18:26:46 -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 8177 invoked by uid 89); 6 Oct 2016 18:26:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=setjmp, troubled, deeply, opportunity X-HELO: mail-qk0-f171.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=VU8ZoQKxrwiCBRgN1hYzjrs11CLHriGtSNUtcYrwAY0=; b=NR7c3kaRJ+ifOI/b95PTdbSmGtOowJZoOYmEWcwtIyrI2+k42ah3gDkE1F7iKGLLmu IgSBh86YldTXWTGbCExuKUWE9eNIB196KpayzG6E2JRVutpQxQv/xf0wnyd1m1+oYQr8 b953cc3g/OStpu/oNPU0nsvGsOnO+teHNJln4m21VRKoXZ8ExWah/70ATuhKRcW0wLrV gFgUWiRDv4kxmcNoMxP+vJTW+jITsdT2FRsMxlRcH7InyKMPgFWlfgUpBY98CZ0NJ49X +Wgw97W3L8fqnX9rUeW0kaYHRRt1J6Ml8X6T9Lpr9qvJ4qjxhf4WQFzfXJjBO1RNIEMW rISA== X-Gm-Message-State: AA6/9Rm7gVU2Xxc0ZW6F1SQDrS9NSPvq1/cpi79fY1/RvpjglBoBcVxhgIZyy/h17mFpoARu3S7TDTsUjExNvw== X-Received: by 10.55.33.135 with SMTP id f7mr12872249qki.141.1475778394029; Thu, 06 Oct 2016 11:26:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161006180514.GP19318@brightrain.aerifal.cx> References: <20161006172631.GO19318@brightrain.aerifal.cx> <20161006180514.GP19318@brightrain.aerifal.cx> From: =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= Date: Thu, 06 Oct 2016 18:26:00 -0000 Message-ID: Subject: Re: Caching of PID/TID after fork To: Rich Felker Cc: GLIBC Devel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-10/txt/msg00146.txt.bz2 >> 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-exec= ve.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? Admittedly, they probably could... it's just the clone interface is probably supposed to be used by projects like that (non trivial ones, depending deeply on kernel interfaces), and it seems that the authors of those non-trivial tools (possibly, quite experienced in the area of computer architectures) are somewhat troubled by the current glibc behavior. Therefore, maybe there's some opportunity here for glibc to provide them with an interface which might better suit their needs. In my opinion, the path that every future developer dealing with this issue have to take (from analyzing the kernel's __NR_clone implementation to by-passing glibc wrapper with setjmp/longjmp) might be a bit more complex than it should. --=20 Robert =C5=9Awi=C4=99cki