Re: [RFC PATCH v2 02/13] x86/um: nommu: elf loader for fdpic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hajime,

On 14/11/24 09:32, Hajime Tazaki wrote:
On Wed, 13 Nov 2024 22:55:02 +0900,
Geert Uytterhoeven wrote:
On Wed, Nov 13, 2024 at 2:17 PM Hajime Tazaki <thehajime@xxxxxxxxx> wrote:
On Wed, 13 Nov 2024 19:27:08 +0900,
Geert Uytterhoeven wrote:
On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:

-       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
+       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)

s/UML/X86/?

I guess the fdpic loader can be used to X86, but this patchset only
adds UML to be able to select it.  I intended to add UML into nommu
family.

While currently x86-nommu is supported for UML only, this is really
x86-specific. I still hope UML will get support for other architectures
one day, at which point a dependency on UML here will become wrong...


X86 isn't set for UML, X64_32 and X64_64 are though.

Given that the no-MMU UM support even is 64-bit only, that probably
should then really be (UML && X86_64).

But it already has !MMU, so can't be selected otherwise, and it seems
that non-X86 UML

... would require far more changes in all kinds of places, so not sure
I'd be too concerned about it here.

OK, up to you...

Indeed, this particular patch [02/13] intends to support the fdpic
loader under the condition 1) x86_64 ELF binaries (w/ PIE), 2) on UML,
3) and with) !MMU configured.  Given that situation, the strict check
should be like:

    depends on ARM || ((M68K || RISCV || SUPERH || (UML && X86_64) || XTENSA) && !MMU)

(as Johannes mentioned).

on the other hand, the fdpic loader works (afaik) on MMU environment so,

    depends on ARM || (UML && X86_64) || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)

should also works, but this might be too broad for this patchset (and
not sure if this makes a new use case).

AFAIK that depends on the architecture's MMU context structure, cfr.
the comment in commit 782f4c5c44e7d99d ("m68knommu: allow elf_fdpic
loader to be selected"), which restricts it to nommu on m68k.  If it
does work on X86_64, you can drop the dependency on UML, and we're
(almost) back to my initial comment ;-)

I checked and it doesn't work as-is with (UML_X86_64 && MMU).
restricting nommu with UML might be a good to for this patch.

even if it works, I would like to focus on UML && !MMU for this patch
series since I wish to make the (initial) patchset as small as
possible.  If we would like to make it broadly available on x86, that
would be a different patch.

Makes sense.

I was only interested in the ability to run ELF based static/PIE binaries
when I did 782f4c5c44e7d99d ("m68knommu: allow elf_fdpic loader to be selected").
I did the same thing for RISC-V in commit 9549fb354ef1 ("riscv: support the
elf-fdpic binfmt loader"), limiting it to !MMU configurations only.

There is no need for binfmt_fdpic in MMU configurations if all you want to
do is run ELF PIE binaries. The normal binfmt_elf loader can load and run
those already.

Regards
Greg



anyway, thank you for the comment.
# I really wanted to have comments from nommu folks.

I've added some in CC...

Thanks,

-- Hajime




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux