From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964959AbbJOCJi (ORCPT ); Wed, 14 Oct 2015 22:09:38 -0400 Received: from icp-osb-irony-out8.external.iinet.net.au ([203.59.1.225]:15815 "EHLO icp-osb-irony-out8.external.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932968AbbJOCJc (ORCPT ); Wed, 14 Oct 2015 22:09:32 -0400 X-Greylist: delayed 134019 seconds by postgrey-1.27 at vger.kernel.org; Wed, 14 Oct 2015 22:09:31 EDT X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkBAEwKH1ZnMNI1/2dsb2JhbAANUYRoqEIBAQEBAQEGkDuGCYYcAoIOAQEBAQEBhTEBAQEDASMPAUYFCwsNAQcDAgIFIQICDwJGBg0GAgEBiCKvCXGTSwEBAQEBAQEDAQEBAQEdgSKFDYVFhQ0HgmmBRQWHRYZ6h1iWRYVzjG6DJ4FRX4ZvAQEB X-IronPort-AV: E=Sophos;i="5.17,683,1437408000"; d="scan'208";a="986375393" Subject: Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries To: Rich Felker References: <20151008163810.GX8645@brightrain.aerifal.cx> <561CFF51.40909@uclinux.org> <20151013154940.GR8645@brightrain.aerifal.cx> Cc: linux-embedded@vger.kernel.org, Paul Gortmaker , Matt Mackall , David Woodhouse , Alexander Viro , David Howells , Oleg Endo , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org From: Greg Ungerer Message-ID: <561F0ADA.40504@uclinux.org> Date: Thu, 15 Oct 2015 12:09:30 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151013154940.GR8645@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rich, On 14/10/15 01:49, Rich Felker wrote: > On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote: >> Hi Rich, >> >> On 09/10/15 02:38, Rich Felker wrote: >>> From: Rich Felker >>> >>> The ELF binary loader in binfmt_elf.c requires an MMU, making it >>> impossible to use regular ELF binaries on NOMMU archs. However, the >>> FDPIC ELF loader in binfmt_elf_fdpic.c is fully capable as a loader >>> for plain ELF, which requires constant displacements between LOAD >>> segments, since it already supports FDPIC ELF files flagged as needing >>> constant displacement. >>> >>> This patch adjusts the FDPIC ELF loader to accept non-FDPIC ELF files >>> on NOMMU archs. They are treated identically to FDPIC ELF files with >>> the constant-displacement flag bit set, except for personality, which >>> must match the ABI of the program being loaded; the PER_LINUX_FDPIC >>> personality controls how the kernel interprets function pointers >>> passed to sigaction. >>> >>> Files that do not set a stack size requirement explicitly are given a >>> default stack size (matching the amount of committed stack the normal >>> ELF loader for MMU archs would give them) rather than being rejected; >>> this is necessary because plain ELF files generally do not declare >>> stack requirements in theit program headers. >>> >>> Only ET_DYN (PIE) format ELF files are supported, since loading at a >>> fixed virtual address is not possible on NOMMU. >>> >>> Signed-off-by: Rich Felker >> >> I have no problem with this, so from me: >> >> Acked-by: Greg Ungerer > > Thanks! > >>> --- >>> >>> This patch was developed and tested on J2 (SH2-compatible) but should >>> be usable immediately on all archs where binfmt_elf_fdpic is >>> available. Moreover, by providing dummy definitions of the >>> elf_check_fdpic() and elf_check_const_displacement() macros for archs >>> which lack an FDPIC ABI, it should be possible to enable building of >>> binfmt_elf_fdpic on all other NOMMU archs and thereby give them ELF >>> binary support, but I have not yet tested this. >> >> There is a couple of other details that will currently stop this from >> working on other arches too. >> >> .. kernel/ptrace.c has some fdpic specific code (wanting PTRACE_GETFDPIC) >> .. arch specific mm_context_t may not have members >> ‘interp_fdpic_loadmap' or 'exec_fdpic_loadmap' >> >> Should be easy to fix those. > > I see. For archs that lack an FDPIC ABI, I'm not sure it makes sense > to add these things unless/until someone developes an FDPIC ABI. Would Ok. I was looking at it from the point of view of supoporting ELF on m68k/coldfire, that doesn't currently support FDPIC. So bypassing FDPIC support completely. > it instead make sense to add a new kconfig switch > CONFIG_BINFMT_ELF_NOMMU ("NOMMU ELF loader") that's implied-on by > CONFIG_BINFMT_ELF_FDPIC but that can also be enabled independently on > archs where CONFIG_BINFMT_ELF_FDPIC is not available? Yes that may be the only answer here. > Right now these are just ideas. Unless there's a quick and easy > decision to be made, I'd like it if we could move forward with the > current patch (which only offers the feature on archs where > CONFIG_BINFMT_ELF_FDPIC is already available) first and continue to > explore options for making this available to other archs separately. Oh, yes. No problem with that. Looks like Andrew has picked it up. So all good there. >> It would be good to get some testing and verification on other >> fdpic supported arches (frv or blackfin or microblaze for example). > > I wasn't aware Microblaze had an FDPIC ABI; are you sure it does? Sorry, my mistake. No microblaze FDPIC as far as I know. Regards Greg > Testing to make sure these aren't broken by the patch shouldn't be > hard to do; I'll start looking into getting a setup for it or finding > someone who has one. If you want to also test non-FDPIC ELF binaries, > I think just using the ELF output of a bFLT toolchain without running > elf2flt may work as a test case, but I'm not sure. Alternatively, any > FDPIC binary linked with -pie that doesn't use signals can run as a > non-FDPIC one just by clearing the FDPIC bit in the header. > > Rich >