linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: 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,
	gerg@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: Sun, 24 Apr 2022 22:38:58 -0500	[thread overview]
Message-ID: <ab454879-5506-fe7d-cd59-812a6bc9d193@landley.net> (raw)
In-Reply-To: <202204201044.ACFEB0C@keescook>

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


  parent reply	other threads:[~2022-04-25  3:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14  9:10 [PATCH v2] binfmt_flat: do not stop relocating GOT entries prematurely on riscv Niklas Cassel
2022-04-14 23:05 ` Kees Cook
2022-04-15  1:24   ` Niklas Cassel
2022-04-14 23:27 ` Kees Cook
2022-04-14 23:41   ` Damien Le Moal
2022-04-15  1:26   ` Konstantin Ryabitsev
2022-04-16  0:14     ` Kees Cook
2022-04-14 23:51 ` Damien Le Moal
2022-04-15  0:30   ` Niklas Cassel
2022-04-15  0:56     ` Damien Le Moal
2022-04-15  1:08       ` Niklas Cassel
2022-04-15  1:13         ` Damien Le Moal
2022-04-15  2:11           ` Niklas Cassel
2022-04-15  2:14             ` Damien Le Moal
2022-04-20  4:04     ` Greg Ungerer
2022-04-20 14:58       ` [PATCH] binfmt_flat: Remove shared library support Eric W. Biederman
2022-04-20 16:17         ` Palmer Dabbelt
2022-04-20 16:59           ` Rich Felker
2022-04-20 17:47             ` Kees Cook
2022-04-20 20:04               ` Arnd Bergmann
2022-04-20 20:23                 ` Rich Felker
2022-04-20 23:00                   ` Damien Le Moal
2022-04-25  3:38               ` Rob Landley [this message]
2022-04-25  7:40                 ` Greg Ungerer
2022-04-20 23:36         ` Damien Le Moal
2022-04-20 23:53         ` Greg Ungerer
2022-04-21  6:52           ` Geert Uytterhoeven
2022-04-21  7:12             ` Arnd Bergmann
2022-04-22 10:26               ` Vladimir Murzin
2022-04-22 15:18               ` Patrice CHOTARD
2022-04-21 12:43             ` Rich Felker
2022-04-25  3:50               ` Rob Landley
2022-04-21  0:05         ` (subset) " Kees Cook
2022-04-16  4:25 ` [PATCH v2] binfmt_flat: do not stop relocating GOT entries prematurely on riscv Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab454879-5506-fe7d-cd59-812a6bc9d193@landley.net \
    --to=rob@landley.net \
    --cc=Niklas.Cassel@wdc.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=dalias@libc.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=ebiederm@xmission.com \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=stable@vger.kernel.org \
    --cc=vapier@gentoo.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox