Re: [PATCH] binfmt_flat: Remove shared library support

From: Greg Ungerer <gerg@linux-m68k.org>
To: Rob Landley <rob@landley.net>, Kees Cook <keescook@chromium.org>,
	Rich Felker <dalias@libc.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	ebiederm@xmission.com, damien.lemoal@opensource.wdc.com,
	Niklas.Cassel@wdc.com, viro@zeniv.linux.org.uk,
	Paul Walmsley <paul.walmsley@sifive.com>,
	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
Subject: Re: [PATCH] binfmt_flat: Remove shared library support
Date: Mon, 25 Apr 2022 17:40:46 +1000	[thread overview]
Message-ID: <ee410d9d-25dc-3b87-08d2-c4c8e71575a3@linux-m68k.org> (raw)
In-Reply-To: <ab454879-5506-fe7d-cd59-812a6bc9d193@landley.net>

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