Message ID | ea2a3fb86915664d54ba174e043046f684e7cf8c.1731290567.git.thehajime@gmail.com |
---|---|
State | RFC |
Headers | show |
Series | nommu UML | expand |
Hi Tazaki-san, On Mon, Nov 11, 2024 at 7:28 AM Hajime Tazaki <thehajime@gmail.com> wrote: > 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. > > Cc: Eric Biederman <ebiederm@xmission.com> > Cc: Kees Cook <kees@kernel.org> > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > Cc: Christian Brauner <brauner@kernel.org> > Cc: Jan Kara <jack@suse.cz> > Cc: linux-mm@kvack.org > Cc: linux-fsdevel@vger.kernel.org > Signed-off-by: Hajime Tazaki <thehajime@gmail.com> > Signed-off-by: Ricardo Koller <ricarkol@google.com> Thanks for your patch! > --- a/fs/Kconfig.binfmt > +++ b/fs/Kconfig.binfmt > @@ -58,7 +58,7 @@ config ARCH_USE_GNU_PROPERTY > config BINFMT_ELF_FDPIC > bool "Kernel support for FDPIC ELF binaries" > default y if !BINFMT_ELF > - depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) > + depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU) s/UML/X86/? > select ELFCORE > help > ELF FDPIC binaries are based on ELF, but allow the individual load Gr{oetje,eeting}s, Geert
Hello Geert, thank you for the message. On Tue, 12 Nov 2024 21:48:28 +0900, Geert Uytterhoeven wrote: > > On Mon, Nov 11, 2024 at 7:28 AM Hajime Tazaki <thehajime@gmail.com> wrote: > > 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. > > > > Cc: Eric Biederman <ebiederm@xmission.com> > > Cc: Kees Cook <kees@kernel.org> > > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > > Cc: Christian Brauner <brauner@kernel.org> > > Cc: Jan Kara <jack@suse.cz> > > Cc: linux-mm@kvack.org > > Cc: linux-fsdevel@vger.kernel.org > > Signed-off-by: Hajime Tazaki <thehajime@gmail.com> > > Signed-off-by: Ricardo Koller <ricarkol@google.com> > > Thanks for your patch! > > > --- a/fs/Kconfig.binfmt > > +++ b/fs/Kconfig.binfmt > > @@ -58,7 +58,7 @@ config ARCH_USE_GNU_PROPERTY > > config BINFMT_ELF_FDPIC > > bool "Kernel support for FDPIC ELF binaries" > > default y if !BINFMT_ELF > > - 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. -- Hajime
Hi Tazaki-san, On Tue, Nov 12, 2024 at 11:07 PM Hajime Tazaki <thehajime@gmail.com> wrote: > On Tue, 12 Nov 2024 21:48:28 +0900, > > On Mon, Nov 11, 2024 at 7:28 AM Hajime Tazaki <thehajime@gmail.com> wrote: > > > 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. > > > > > > Cc: Eric Biederman <ebiederm@xmission.com> > > > Cc: Kees Cook <kees@kernel.org> > > > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > > > Cc: Christian Brauner <brauner@kernel.org> > > > Cc: Jan Kara <jack@suse.cz> > > > Cc: linux-mm@kvack.org > > > Cc: linux-fsdevel@vger.kernel.org > > > Signed-off-by: Hajime Tazaki <thehajime@gmail.com> > > > Signed-off-by: Ricardo Koller <ricarkol@google.com> > > > > Thanks for your patch! > > > > > --- a/fs/Kconfig.binfmt > > > +++ b/fs/Kconfig.binfmt > > > @@ -58,7 +58,7 @@ config ARCH_USE_GNU_PROPERTY > > > config BINFMT_ELF_FDPIC > > > bool "Kernel support for FDPIC ELF binaries" > > > default y if !BINFMT_ELF > > > - 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... Gr{oetje,eeting}s, Geert
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 johannes
(sorry, fat-fingered that) 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. johannes
Hi Johannes, On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <johannes@sipsolutions.net> 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... Gr{oetje,eeting}s, Geert
Hello, thanks for the inputs Geert, Johannes, On Wed, 13 Nov 2024 19:27:08 +0900, Geert Uytterhoeven wrote: > > Hi Johannes, > > On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <johannes@sipsolutions.net> 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). anyway, thank you for the comment. # I really wanted to have comments from nommu folks. -- Hajime
Hi Tazaki-san, On Wed, Nov 13, 2024 at 2:17 PM Hajime Tazaki <thehajime@gmail.com> 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@sipsolutions.net> 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 ;-) > anyway, thank you for the comment. > # I really wanted to have comments from nommu folks. I've added some in CC... Gr{oetje,eeting}s, Geert
On Wed, 13 Nov 2024 22:55:02 +0900, Geert Uytterhoeven wrote: > On Wed, Nov 13, 2024 at 2:17 PM Hajime Tazaki <thehajime@gmail.com> 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@sipsolutions.net> 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. > > anyway, thank you for the comment. > > # I really wanted to have comments from nommu folks. > > I've added some in CC... Thanks, -- Hajime
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@gmail.com> 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@sipsolutions.net> 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
Hello Greg, On Thu, 14 Nov 2024 10:40:03 +0900, Greg Ungerer wrote: > 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. Yes, my motivation to use this loader is run elf PIE binaries under !MMU environment. -- Hajime
diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild index 18f902da8e99..cf8260fdcfe5 100644 --- a/arch/um/include/asm/Kbuild +++ b/arch/um/include/asm/Kbuild @@ -14,6 +14,7 @@ generic-y += irq_work.h generic-y += kdebug.h generic-y += mcs_spinlock.h generic-y += mmiowb.h +generic-y += module.h generic-y += module.lds.h generic-y += param.h generic-y += parport.h diff --git a/arch/um/include/asm/mmu.h b/arch/um/include/asm/mmu.h index a3eaca41ff61..01422b761aa0 100644 --- a/arch/um/include/asm/mmu.h +++ b/arch/um/include/asm/mmu.h @@ -14,6 +14,11 @@ typedef struct mm_context { /* Address range in need of a TLB sync */ unsigned long sync_tlb_range_from; unsigned long sync_tlb_range_to; + +#ifdef CONFIG_BINFMT_ELF_FDPIC + unsigned long exec_fdpic_loadmap; + unsigned long interp_fdpic_loadmap; +#endif } mm_context_t; #endif diff --git a/arch/um/include/asm/ptrace-generic.h b/arch/um/include/asm/ptrace-generic.h index 4696f24d1492..4ff844bcb1cd 100644 --- a/arch/um/include/asm/ptrace-generic.h +++ b/arch/um/include/asm/ptrace-generic.h @@ -29,6 +29,12 @@ struct pt_regs { #define PTRACE_OLDSETOPTIONS 21 +#ifdef CONFIG_BINFMT_ELF_FDPIC +#define PTRACE_GETFDPIC 31 +#define PTRACE_GETFDPIC_EXEC 0 +#define PTRACE_GETFDPIC_INTERP 1 +#endif + struct task_struct; extern long subarch_ptrace(struct task_struct *child, long request, diff --git a/arch/x86/um/asm/elf.h b/arch/x86/um/asm/elf.h index 62ed5d68a978..33f69f1eac10 100644 --- a/arch/x86/um/asm/elf.h +++ b/arch/x86/um/asm/elf.h @@ -9,6 +9,7 @@ #include <skas.h> #define CORE_DUMP_USE_REGSET +#define ELF_FDPIC_CORE_EFLAGS 0 #ifdef CONFIG_X86_32 @@ -190,8 +191,11 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm, extern unsigned long um_vdso_addr; #define AT_SYSINFO_EHDR 33 -#define ARCH_DLINFO NEW_AUX_ENT(AT_SYSINFO_EHDR, um_vdso_addr) - +#define ARCH_DLINFO \ +do { \ + NEW_AUX_ENT(AT_SYSINFO_EHDR, um_vdso_addr); \ + NEW_AUX_ENT(AT_MINSIGSTKSZ, 0); \ +} while (0) #endif typedef unsigned long elf_greg_t; diff --git a/arch/x86/um/asm/module.h b/arch/x86/um/asm/module.h deleted file mode 100644 index a3b061d66082..000000000000 --- a/arch/x86/um/asm/module.h +++ /dev/null @@ -1,24 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __UM_MODULE_H -#define __UM_MODULE_H - -/* UML is simple */ -struct mod_arch_specific -{ -}; - -#ifdef CONFIG_X86_32 - -#define Elf_Shdr Elf32_Shdr -#define Elf_Sym Elf32_Sym -#define Elf_Ehdr Elf32_Ehdr - -#else - -#define Elf_Shdr Elf64_Shdr -#define Elf_Sym Elf64_Sym -#define Elf_Ehdr Elf64_Ehdr - -#endif - -#endif diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt index bd2f530e5740..419ba0282806 100644 --- a/fs/Kconfig.binfmt +++ b/fs/Kconfig.binfmt @@ -58,7 +58,7 @@ config ARCH_USE_GNU_PROPERTY config BINFMT_ELF_FDPIC bool "Kernel support for FDPIC ELF binaries" default y if !BINFMT_ELF - depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) + depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU) select ELFCORE help ELF FDPIC binaries are based on ELF, but allow the individual load