| Message ID | d387e58f08b929357a2651e82d2ee18bcf681e40.1733998168.git.thehajime@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
Hajime Tazaki <thehajime@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? 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. 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. 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. Eric > 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> > --- > arch/um/include/asm/mmu.h | 5 +++++ > arch/um/include/asm/ptrace-generic.h | 6 ++++++ > arch/x86/um/asm/elf.h | 8 ++++++-- > fs/Kconfig.binfmt | 2 +- > 4 files changed, 18 insertions(+), 3 deletions(-) > > 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/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
Hello Eric, thanks for the feedback. On Thu, 12 Dec 2024 23:22:47 +0900, Eric W. Biederman wrote: > > Hajime Tazaki <thehajime@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. > 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. 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. -- Hajime
Hajime Tazaki <thehajime@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@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
On Sat, 14 Dec 2024 05:01:58 +0900, Eric W. Biederman wrote: > >> 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. hmm, at least MAP_FIXED doesn't work in current mm/nommu.c. # also documented at Documentation/admin-guide/mm/nommu-mmap.rst. > > 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. If I applied to below in addition to my whole patchset, diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt index 419ba0282806..b34d0578a22f 100644 --- a/fs/Kconfig.binfmt +++ b/fs/Kconfig.binfmt @@ -4,7 +4,6 @@ menu "Executable file formats" config BINFMT_ELF bool "Kernel support for ELF binaries" - depends on MMU select ELFCORE default y help @@ -58,7 +57,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 || UML || XTENSA) && !MMU) + depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) select ELFCORE help ELF FDPIC binaries are based on ELF, but allow the individual load this is the output from `make ARCH=um`. GEN Makefile CALL ../scripts/checksyscalls.sh CC fs/binfmt_elf.o In file included from ./arch/x86/include/generated/asm/rwonce.h:1, from ../include/linux/compiler.h:317, from ../include/linux/build_bug.h:5, from ../include/linux/container_of.h:5, from ../include/linux/list.h:5, from ../include/linux/module.h:12, from ../fs/binfmt_elf.c:13: ../fs/binfmt_elf.c: In function ‘load_elf_binary’: ../include/asm-generic/rwonce.h:44:71: error: lvalue required as unary ‘&’ operand 44 | #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) | ^ ../include/asm-generic/rwonce.h:50:9: note: in expansion of macro ‘__READ_ONCE’ 50 | __READ_ONCE(x); \ | ^~~~~~~~~~~ ../fs/binfmt_elf.c:1006:49: note: in expansion of macro ‘READ_ONCE’ 1006 | const int snapshot_randomize_va_space = READ_ONCE(randomize_va_space); | I avoided this issue (with nasty MAP_FIXED workaround) but there seems to be still a lot of things that I need to fix to work with nommu. > 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 understand your concern, and will try to work on improving this situation a bit. Another naive question: are there any past attempts to do the similar thing (binfmt_elf without MMU) ? -- Hajime
Hajime Tazaki <thehajime@gmail.com> writes: > On Sat, 14 Dec 2024 05:01:58 +0900, > Eric W. Biederman wrote: > >> >> 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. > > hmm, at least MAP_FIXED doesn't work in current mm/nommu.c. > # also documented at Documentation/admin-guide/mm/nommu-mmap.rst. Yes, and that fundamentally makes sense. >> > 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. > > If I applied to below in addition to my whole patchset, > > diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt > index 419ba0282806..b34d0578a22f 100644 > --- a/fs/Kconfig.binfmt > +++ b/fs/Kconfig.binfmt > @@ -4,7 +4,6 @@ menu "Executable file formats" > > config BINFMT_ELF > bool "Kernel support for ELF binaries" > - depends on MMU > select ELFCORE > default y > help > @@ -58,7 +57,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 || UML || XTENSA) && !MMU) > + depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) > select ELFCORE > help > ELF FDPIC binaries are based on ELF, but allow the individual load You have my apologies I was most definitely confused. BINFMT_ELF currently does not work without an MMU. > this is the output from `make ARCH=um`. > > GEN Makefile > CALL ../scripts/checksyscalls.sh > CC fs/binfmt_elf.o > In file included from ./arch/x86/include/generated/asm/rwonce.h:1, > from ../include/linux/compiler.h:317, > from ../include/linux/build_bug.h:5, > from ../include/linux/container_of.h:5, > from ../include/linux/list.h:5, > from ../include/linux/module.h:12, > from ../fs/binfmt_elf.c:13: > ../fs/binfmt_elf.c: In function ‘load_elf_binary’: > ../include/asm-generic/rwonce.h:44:71: error: lvalue required as unary ‘&’ operand > 44 | #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) > | ^ > ../include/asm-generic/rwonce.h:50:9: note: in expansion of macro ‘__READ_ONCE’ > 50 | __READ_ONCE(x); \ > | ^~~~~~~~~~~ > ../fs/binfmt_elf.c:1006:49: note: in expansion of macro ‘READ_ONCE’ > 1006 | const int snapshot_randomize_va_space = READ_ONCE(randomize_va_space); > | > > I avoided this issue (with nasty MAP_FIXED workaround) but there seems > to be still a lot of things that I need to fix to work with nommu. Yes, at a minimum all of the MAP_FIXED code would need to be conditionalized on having an MMU. > >> 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 understand your concern, and will try to work on improving this > situation a bit. > > Another naive question: are there any past attempts to do the similar > thing (binfmt_elf without MMU) ? At this point what I would recommend is: Merge your original patch. Get nommu UML working with binfmt_elf_fdpic.c. I think it is a proper superset of ELF functionality. Then I would make it a long term goal to see about removing redundancy between binfmt_elf.c and binfmt_elf_fdpic.c with a view to merging them in the long term. There is a lot of mostly duplicate code between the two and binfmt_elf_fdpic.c does not get half the attention and use binfmt_elf.c gets. Eric
On Sat, 14 Dec 2024 06:53:44 +0900, Eric W. Biederman wrote: > > config BINFMT_ELF > > bool "Kernel support for ELF binaries" > > - depends on MMU > > select ELFCORE > > default y > > help > > @@ -58,7 +57,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 || UML || XTENSA) && !MMU) > > + depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) > > select ELFCORE > > help > > ELF FDPIC binaries are based on ELF, but allow the individual load > > You have my apologies I was most definitely confused. BINFMT_ELF > currently does not work without an MMU. no problem. > >> 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 understand your concern, and will try to work on improving this > > situation a bit. > > > > Another naive question: are there any past attempts to do the similar > > thing (binfmt_elf without MMU) ? > > At this point what I would recommend is: > > Merge your original patch. Get nommu UML working with binfmt_elf_fdpic.c. > I think it is a proper superset of ELF functionality. > > Then I would make it a long term goal to see about removing redundancy > between binfmt_elf.c and binfmt_elf_fdpic.c with a view to merging them > in the long term. > > There is a lot of mostly duplicate code between the two and > binfmt_elf_fdpic.c does not get half the attention and use binfmt_elf.c > gets. thanks for the recommendation. I'll go for this direction. It would be great if nommu arch (at least) UML can use the regular binfmt_elf. -- Hajime
On Thu, Dec 12, 2024 at 07:12:09PM +0900, Hajime Tazaki 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> Acked-by: Kees Cook <kees@kernel.org>
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/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