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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79266C433F5 for ; Mon, 25 Apr 2022 07:40:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D5228D000F; Mon, 25 Apr 2022 03:40:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0861C8D0006; Mon, 25 Apr 2022 03:40:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8E9F8D000F; Mon, 25 Apr 2022 03:40:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id D79518D0006 for ; Mon, 25 Apr 2022 03:40:55 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id B7599623D3 for ; Mon, 25 Apr 2022 07:40:55 +0000 (UTC) X-FDA: 79394604870.06.946901C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 3E060A0043 for ; Mon, 25 Apr 2022 07:40:49 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8DD9E612FB; Mon, 25 Apr 2022 07:40:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39F0AC385A4; Mon, 25 Apr 2022 07:40:49 +0000 (UTC) Message-ID: Date: Mon, 25 Apr 2022 17:40:46 +1000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] binfmt_flat: Remove shared library support Content-Language: en-US To: Rob Landley , Kees Cook , Rich Felker Cc: Palmer Dabbelt , ebiederm@xmission.com, damien.lemoal@opensource.wdc.com, Niklas.Cassel@wdc.com, viro@zeniv.linux.org.uk, Paul Walmsley , aou@eecs.berkeley.edu, vapier@gentoo.org, stable@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org, geert@linux-m68k.org, linux-m68k@lists.linux-m68k.org, linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org, ysato@users.sourceforge.jp References: <87levzzts4.fsf_-_@email.froward.int.ebiederm.org> <20220420165935.GA12207@brightrain.aerifal.cx> <202204201044.ACFEB0C@keescook> From: Greg Ungerer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3E060A0043 X-Stat-Signature: u5ki1e6ai54g7ezg75piifre6bqwqggg X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf25.hostedemail.com: domain of "SRS0=/+/R=VD=linux-m68k.org=gerg@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=/+/R=VD=linux-m68k.org=gerg@kernel.org" X-Rspamd-Server: rspam09 X-HE-Tag: 1650872449-41578 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 25/4/22 13:38, Rob Landley wrote: > On 4/20/22 12:47, Kees Cook wrote: >>> For what it's worth, bimfmt_flat (with or without shared library >>> support) should be simple to implement as a binfmt_misc handler if >>> anyone needs the old shared library support (or if kernel wanted to >>> drop it entirely, which I would be in favor of). That's how I handled >>> old aout binaries I wanted to run after aout was removed: trivial >>> binfmt_misc loader. >> >> Yeah, I was trying to understand why systems were using binfmt_flat and >> not binfmt_elf, given the mention of elf2flat -- is there really such a >> large kernel memory footprint savings to be had from removing >> binfmt_elf? > > elf2flat is a terrible name: it doesn't take an executable as input, it takes a > .o file as input. (I mean it's an elf format .o file, but... misleading.) No, not at all. "elf2flt" is exactly what it does. Couldn't get a more accurate name. >> But regardless, yes, it seems like if you're doing anything remotely >> needing shared libraries with binfmt_flat, such a system could just use >> ELF instead. > > A) The binfmt_elf.c loader won't run on nommu systems. The fdpic loader will, > and in theory can handle normal ELF binaries (it's ELF with _more_ > capabilities), but sadly it's not supported on most architectures for reasons > that are unclear to me. Inertia. Flat format has been around a very long time. And for most people it just works. Flat format works on MMU systems as well, though you would have to be crazy to choose to do that. > B) You can't run conventional ELF on nommu, because everything is offset from 0 > so PID 1 eats that address range and you can't run exec program. > > You can run PIE binaries on nommu (the symbols offset from a base pointer which > can point anywhere), but they're inefficient (can't share text or rodata > sections between instances because every symbol is offset from a single shared > base pointer), and highly vulnerable to fragmentation (because it needs a > contiguous blob of memory for text, rodata, bss, and data: see single base > pointer everything has an integer offset from). > > All fdpic really does is give you 4 base pointers, one for each section. That > way you can share text and rodata, and put bss and data into smaller independent > fragments of memory. Various security guys use this as super-aslr even on mmu > systems, but tend not to advertise that they're doing so. :) Well flat got half way there. You can have separate text/rodata and data/bss, used a lot back in the day for execute-in-place of the code. Regards Greg