[PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Eric W. Biederman]

Hajime Tazaki <thehajime at gmail.com> writes:

> Hello Eric,
>
> thanks for the feedback.
>
> On Thu, 12 Dec 2024 23:22:47 +0900,
> Eric W. Biederman wrote:
>> 
>> Hajime Tazaki <thehajime at gmail.com> writes:
>> 
>> > As UML supports CONFIG_MMU=n case, it has to use an alternate ELF
>> > loader, FDPIC ELF loader.  In this commit, we added necessary
>> > definitions in the arch, as UML has not been used so far.  It also
>> > updates Kconfig file to use BINFMT_ELF_FDPIC under !MMU environment.
>> 
>> Why does the no mmu case need an alternative elf loader?
>
> I was simply following the way how other nommu architectures (riscv,
> etc) did.
>
>> Last time I looked the regular binfmt_elf works just fine
>> without an mmu.  I looked again and at a quick skim the
>> regular elf loader still looks like it will work without
>> an MMU.
>
> I'm wondering how you looked at it and how you see that it works
> without MMU.

I got as far as seeing that vm_mmap should work.  As all of the
bits for mmap to work, are present in both mmu and nommu.

>> You would need ET_DYN binaries just so they will load and run
>> in a position independent way.  But even that seems a common
>> configuration even with a MMU these days.
>
> Yes, our perquisite for this nommu port is to use PIE binaries so,
> ET_DYN assumption works fine for the moment.
>
>> There are some funny things in elf_fdpic where it departs
>> from the ELF standard and is no fun to support unless it
>> is necessary.  So I am not excited to see more architectures
>> supporting ELF_FDPIC.
>
> I understand.
>
> I also wish to use the regular binfmt_elf, but it doesn't allow me to
> compile with !CONFIG_MMU right now.

Then I may simply be confused.  Where does the compile fail?
Is it somewhere in Kconfig?

I could be completely confused.  It has happened before.

I just react a little strongly to the assertion that elf_fdpic is
the only path when I don't see why that should be.

Especially for an architecture like user-mode-linux where I would expect
it to run the existing binaries for a port.

> I've played a little bit with touching binfmt_elf.c, but not finished
> yet with a trivial attempt.
>
> sorry, i'm not familiar with this part but wish to fix it for
> nommu+ET_EYN if possible with a right background information.

Eric