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 85D21C433F5 for ; Mon, 25 Apr 2022 03:34:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B36746B00A8; Sun, 24 Apr 2022 23:34:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE4E86B00A9; Sun, 24 Apr 2022 23:34:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9862C6B00AA; Sun, 24 Apr 2022 23:34:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 885846B00A8 for ; Sun, 24 Apr 2022 23:34:41 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 51661273A9 for ; Mon, 25 Apr 2022 03:34:41 +0000 (UTC) X-FDA: 79393984362.25.B43DE5E Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf03.hostedemail.com (Postfix) with ESMTP id 014D12002B for ; Mon, 25 Apr 2022 03:34:37 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id t15so15817960oie.1 for ; Sun, 24 Apr 2022 20:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=B1QfoAi5AbmZrNfgKcOMoR0g+jeoWpDUXn39NnppiO8=; b=RP5YQMrqRBjFc1TPzDRF/VNHpK8/m7n4dXSd/cW6Z5KUCS1IKHMEhUBJ5NZBxPSlQe 7w69F6X6ON+ARmCOQU0idD+EYWSxMlBPBMReqAsXwbNBrW3/87epvMb6ASjFylpL/qcT PlQP2jiXuw8pn/O8+w35QVbGxauzbtyJro3+/mru8XCY6zwaT9g3mN7ITl336PH9kTPK lV7kpe0CHmxr5jjvZV36lVm345wKpfd7SjO1S5pwz+Lqc12HAHCQ+CeXXfqmxvVDi/uu 2JS8/XRGqAInv+agUB3X6u1ASYWsrcuw+QvXWEyK0vxNdPObwZHiGre7X9RvphN4xv+E e8fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=B1QfoAi5AbmZrNfgKcOMoR0g+jeoWpDUXn39NnppiO8=; b=Rg4Yz6+/Gfeb7PkFHnZ5XXlVcENh6OqlbOtPb/DQ/uHP3aJ7YobYSlxOy4VrqOuIqd dxEq9OtKnjtC/WvXU5vxLnQYbitJP6eUFowNsGejkaImGRdYZj5T817exy1oOieX5YL+ KN3qqKZNxaJkoERx/XHBOT1JwnzL4pOqzYGvwp2nddUw0v2EI//xEbyDC6ytDa1FfY7x f+2Yk5c2UhNo2b2vm4j6heVOZwJ13uLE2LQ8JIeUertzPCLX0r6/2qEsK6H2hDP6VOQX tSmxTaY/SClS+meLZrRQQxNGbGm9FJSwVXJjSWVP/PkXBnsfX9OYb6yaHLdp5CTP12kN 6qdg== X-Gm-Message-State: AOAM531O8TDBPNmx5W4sKOtwBrqVLWRTlckqN1Cww3qtmow8GNxqvies jLCxrv0M4mkED04wfYoLiq5cEQ== X-Google-Smtp-Source: ABdhPJxo8MI+d6zaUs6uXLuDmIBbvncR0vS1nSWd1hInEUCXQb+VfGu0cvlm09UQJgV/8onv8BD9pw== X-Received: by 2002:a05:6808:1690:b0:325:4159:2004 with SMTP id bb16-20020a056808169000b0032541592004mr214582oib.86.1650857680070; Sun, 24 Apr 2022 20:34:40 -0700 (PDT) Received: from [192.168.208.243] ([172.56.88.231]) by smtp.gmail.com with ESMTPSA id i26-20020a4a929a000000b0033a29c8d564sm3899603ooh.3.2022.04.24.20.34.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Apr 2022 20:34:39 -0700 (PDT) Message-ID: Date: Sun, 24 Apr 2022 22:38:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH] binfmt_flat: Remove shared library support Content-Language: en-US To: 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, gerg@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: Rob Landley In-Reply-To: <202204201044.ACFEB0C@keescook> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 014D12002B X-Stat-Signature: 6akt3n7d8w7sogtjsgabhd3nkd4jiqjh X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=landley-net.20210112.gappssmtp.com header.s=20210112 header.b=RP5YQMrq; spf=none (imf03.hostedemail.com: domain of rob@landley.net has no SPF policy when checking 209.85.167.174) smtp.mailfrom=rob@landley.net; dmarc=none X-HE-Tag: 1650857677-293303 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 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.) > 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. 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. :) Rob