From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rich Felker Date: Thu, 30 Apr 2020 14:51:23 +0000 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> List-Id: References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Ungerer Cc: Mark Salter , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Nicolas Pitre , Linux-sh list , Jann Horn , Russell King - ARM Linux admin , Linux Kernel Mailing List , Linux-MM , Alexander Viro , Oleg Nesterov , linux-fsdevel , Andrew Morton , Aurelien Jacquiot , Linus Torvalds , Christoph Hellwig , Linux ARM , "Eric W . Biederman" 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 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 BDC7AC47247 for ; Thu, 30 Apr 2020 15:08:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A284220661 for ; Thu, 30 Apr 2020 15:08:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727065AbgD3PIs (ORCPT ); Thu, 30 Apr 2020 11:08:48 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:48622 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726350AbgD3PIr (ORCPT ); Thu, 30 Apr 2020 11:08:47 -0400 X-Greylist: delayed 1041 seconds by postgrey-1.27 at vger.kernel.org; Thu, 30 Apr 2020 11:08:47 EDT 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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 A9B56C47247 for ; Thu, 30 Apr 2020 14:56:20 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A7C820775 for ; Thu, 30 Apr 2020 14:56:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JEgGdAo7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A7C820775 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Dul5eTASqph19NYXMNKw+6rZT35LXi5JYuayXlsPdt8=; b=JEgGdAo7/jbLQX kA6gXZp0V4s4T0B3DQ5B5Sir7YgExjtDoyqxfKoJ5uv+k86kflXYKqFe3ODmm4s/xRX3r4fjv/hZr 6TVJKGCqW7D0G5HUd/s5+a0DXwwA47SGjdG3T+x52dwzELnrWgCIXixD7pgYEEn2K/O9oUq1Tj9y4 sj4NjjWp5FVG0z6cAYEV0fayLragTxp9QWyCBdYDvWsgNC4fEVbqos71Hvm3yhHda6Qj3T6Hg7ZEZ tS0HRpImYIIj0SHWdPc1E6sPa7c46EnshYLiSobKOSxe6KGRpDpInIQml1vecoFExOuEaz6qckYB+ Dq1WusXSLf+BceDgWfdA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jUAbn-0005zo-3v; Thu, 30 Apr 2020 14:56:15 +0000 Received: from brightrain.aerifal.cx ([216.12.86.13]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jUAXC-0007wK-GO for linux-arm-kernel@lists.infradead.org; Thu, 30 Apr 2020 14:51:40 +0000 Date: Thu, 30 Apr 2020 10:51:23 -0400 From: Rich Felker To: Greg Ungerer 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-Disposition: inline In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200430_075130_949853_400C20D6 X-CRM114-Status: GOOD ( 19.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Salter , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Nicolas Pitre , Linux-sh list , Jann Horn , Russell King - ARM Linux admin , Linux Kernel Mailing List , Linux-MM , Alexander Viro , Oleg Nesterov , linux-fsdevel , Andrew Morton , Aurelien Jacquiot , Linus Torvalds , Christoph Hellwig , Linux ARM , "Eric W . Biederman" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel