From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6B17C47247 for ; Thu, 30 Apr 2020 14:51:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8FC1B2074A for ; Thu, 30 Apr 2020 14:51:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FC1B2074A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 366A28E0006; Thu, 30 Apr 2020 10:51:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 317968E0005; Thu, 30 Apr 2020 10:51:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22D4B8E0006; Thu, 30 Apr 2020 10:51:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id 070B18E0005 for ; Thu, 30 Apr 2020 10:51:27 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BD8D5180AD811 for ; Thu, 30 Apr 2020 14:51:26 +0000 (UTC) X-FDA: 76764809772.02.plate90_29a7b1ebb050e X-HE-Tag: plate90_29a7b1ebb050e X-Filterd-Recvd-Size: 3929 Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 14:51:25 +0000 (UTC) Date: Thu, 30 Apr 2020 10:51:23 -0400 From: Rich Felker To: Greg Ungerer Cc: Linus Torvalds , Russell King - ARM Linux admin , Jann Horn , Nicolas Pitre , Andrew Morton , Christoph Hellwig , Linux Kernel Mailing List , Linux-MM , linux-fsdevel , Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , Linux ARM , Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Linux-sh list Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there Message-ID: <20200430145123.GE21576@brightrain.aerifal.cx> References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 01, 2020 at 12:10:05AM +1000, Greg Ungerer wrote: > > > On 30/4/20 9:03 am, Linus Torvalds wrote: > >On Wed, Apr 29, 2020 at 2:57 PM Russell King - ARM Linux admin > > wrote: > >> > >>I've never had any reason to use FDPIC, and I don't have any binaries > >>that would use it. Nicolas Pitre added ARM support, so I guess he > >>would be the one to talk to about it. (Added Nicolas.) > > > >While we're at it, is there anybody who knows binfmt_flat? > > > >It might be Nicolas too. > > > >binfmt_flat doesn't do core-dumping, but it has some other oddities. > >In particular, I'd like to bring sanity to the installation of the new > >creds, and all the _normal_ binfmt cases do it largely close together > >with setup_new_exec(). > > > >binfmt_flat is doing odd things. It's doing this: > > > > /* Flush all traces of the currently running executable */ > > if (id == 0) { > > ret = flush_old_exec(bprm); > > if (ret) > > goto err; > > > > /* OK, This is the point of no return */ > > set_personality(PER_LINUX_32BIT); > > setup_new_exec(bprm); > > } > > > >in load_flat_file() - which is also used to loading _libraries_. Where > >it makes no sense at all. > > I haven't looked at the shared lib support in there for a long time, > but I thought that "id" is only 0 for the actual final program. > Libraries have a slot or id number associated with them. This sounds correct. My understanding of FLAT shared library support is that it's really bad and based on having preassigned slot indices for each library on the system, and a global array per-process to give to data base address for each library. Libraries are compiled to know their own slot numbers so that they just load from fixed_reg[slot_id] to get what's effectively their GOT pointer. I'm not sure if anybody has actually used this in over a decade. Last time I looked the tooling appeared broken, but in this domain lots of users have forked private tooling that's not publicly available or at least not publicly indexed, so it's hard to say for sure. Rich