linux-kernel - Re: [Automated-testing] Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d602919e-2cfb-455a-8a90-76f649d92b39@linux-m68k.org>
Date: Thu, 11 Jan 2024 23:19:18 +1000
From: Greg Ungerer <gerg@...ux-m68k.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>, Rob Landley <rob@...dley.net>
Cc: Petr Vorel <pvorel@...e.cz>, Tim Bird <tim.bird@...y.com>,
 Cyril Hrubis <chrubis@...e.cz>, "ltp@...ts.linux.it" <ltp@...ts.linux.it>,
 Li Wang <liwang@...hat.com>, Andrea Cervesato <andrea.cervesato@...e.com>,
 Jonathan Corbet <corbet@....net>, Randy Dunlap <rdunlap@...radead.org>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Christophe Lyon <christophe.lyon@...aro.org>,
 "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Linux ARM <linux-arm-kernel@...ts.infradead.org>,
 linux-riscv <linux-riscv@...ts.infradead.org>,
 Linux-sh list <linux-sh@...r.kernel.org>,
 "automated-testing@...ts.yoctoproject.org"
 <automated-testing@...ts.yoctoproject.org>,
 "buildroot@...ldroot.org" <buildroot@...ldroot.org>,
 Niklas Cassel <niklas.cassel@....com>
Subject: Re: [Automated-testing] Call for nommu LTP maintainer [was: Re:
 [PATCH 00/36] Remove UCLINUX from LTP]


On 11/1/24 23:11, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Wed, Jan 10, 2024 at 8:17 PM Rob Landley <rob@...dley.net> wrote:
>> You can't fork() on nommu because copies of the mappings have different
>> addresses, meaning any pointers in the copied mappings would point into the OLD
>> mappings (belonging to the parent process), and fixing them up is 100%
>> equivalent to the "garbage collection in C" problem. (It's AI-complete. Of the
>> C3PO kind, not the "autocorrect with syntax checking" kind.) People get hung up
>> on the "it would be very inefficient to do that because no copy-on-write"
>> problem and miss the "the child couldn't FUNCTION because its pointer variables
>> all contain parent addresses" problem.
> 
> Actually you can implement fork(), if you teach the compiler to use
> separate stacks for return addresses and data:
>    - The first stack would contain only absolute addresses, to be
>      relocated after copying,
>    - The second stack would contain integers and relative pointers
>      (see FDPIC below), which do not need relocation after copying.
> 
>> The OTHER fun thing about nommu is you can't run conventional ELF binaries,
>> because everything is linked at fixed address. So you might be able to run ONE
>> instance of the program as your init task, assuming those addresses were
>> available even then, but as soon as you try to run a second one it's a conflict.
>>
>> The quick and dirty work around is to make PIE binaries, which can relocate
>> everything into available space, which works but doesn't scale. The problem with
>> ELF PIE is that everything is linked contiguously from a single base pointer,
>> meaning your text, rodata, data, and bss segments are all one linear blob. So if
>> you run two instances of bash, you've loaded two copies of the test and the
>> rodoata. This fills up your memory fast.
>>
>> AND PIE requires contiguous memory, which nommu is bad at providing because it
>> has no page tables to remap stuff. With an mmu it can coalesce scattered
>> physical pages into a virtually contiguous range, but without an mmu you can
>> have plenty of memory free but in tiny chunks, none big enough to satisfy an
>> allocation request.
>>
>> So they invented FDPIC, which is ELF with FOUR base pointers. Each major section
>> (rodata, text, data, and bss) has its own base pointer, so you need to find
>> smaller chunks of memory to load them into (and thus it can work on a more
>> fragmented system), AND it means that two instances of the same program can
>> share the read-only sections (rodata and text) so you only need new copies of
>> the writeable segments (data and bss. And the heap. And the stack.)
> 
> Or Amiga LoadSeg() relocatable binaries and shared libraries ;-)
> As this supported splitting code, data, and bss in lots of smaller
> hunks, it could counter fragmented memory quite well.
> 
> BTW, can't you run and thus test nommu-binaries under normal Linux, too?

Yes, you can. The flat format loader can be built for MMU arm and m68k Linux.
It will happily load and run flat format binaries on normal VM Linux.
I test that often on m68k (on ColdFire platforms).

Regards
Greg