* [PULL REQUEST v2] FDPIC ELF support for ARM @ 2017-08-30 3:16 Nicolas Pitre 2017-09-19 21:14 ` Nicolas Pitre 2020-06-08 22:47 ` Russell King - ARM Linux admin 0 siblings, 2 replies; 6+ messages in thread From: Nicolas Pitre @ 2017-08-30 3:16 UTC (permalink / raw) To: linux-arm-kernel Russell, could you please pull the following: http://git.linaro.org/people/nicolas.pitre/linux fdpic This series provides the needed changes to suport the ELF_FDPIC binary format on ARM. Both MMU and non-MMU systems are supported. This format has many advantages over the BFLT format used on MMU-less systems, such as being real ELF that can be parsed by standard tools, can support shared dynamic libs, etc. This is based on v4.13-rc4 not to conflict with changes to signal.c that happened in v4.13-rc3. A complete toolchain and prebuilt packages can be obtained here: https://github.com/mickael-guene/fdpic_manifest Changes from v1: - Reworked the signal return code to be compatible with a non-executable stack. - Rebased on v4.13-rc4 to pick up latest signal changes. - Added MMU support. - Fixed crash in the ELF-FDPIC loader when loading an executable with shared libs on a system with an MMU. - Made the regular ELF loader reject FDPIC binaries. - Added ACKs and Reviewed-bys. diffstat: arch/arm/include/asm/elf.h | 16 +++++++-- arch/arm/include/asm/mmu.h | 8 +++++ arch/arm/include/asm/processor.h | 22 +++++++++---- arch/arm/include/asm/ucontext.h | 1 + arch/arm/include/uapi/asm/ptrace.h | 4 +++ arch/arm/include/uapi/asm/unistd.h | 1 + arch/arm/kernel/asm-offsets.c | 4 +++ arch/arm/kernel/elf.c | 24 +++++++++++++- arch/arm/kernel/signal.c | 53 +++++++++++++++++++++--------- arch/arm/kernel/signal.h | 11 +++++++ arch/arm/kernel/sigreturn_codes.S | 56 +++++++++++++++++++++++++++++--- arch/arm/kernel/traps.c | 3 ++ fs/Kconfig.binfmt | 4 +-- fs/binfmt_elf.c | 15 +++++++-- fs/binfmt_elf_fdpic.c | 13 ++++++-- 15 files changed, 199 insertions(+), 36 deletions(-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PULL REQUEST v2] FDPIC ELF support for ARM 2017-08-30 3:16 [PULL REQUEST v2] FDPIC ELF support for ARM Nicolas Pitre @ 2017-09-19 21:14 ` Nicolas Pitre 2020-06-08 22:47 ` Russell King - ARM Linux admin 1 sibling, 0 replies; 6+ messages in thread From: Nicolas Pitre @ 2017-09-19 21:14 UTC (permalink / raw) To: linux-arm-kernel Russell, Same deal as with the other pull request: now based on v4.13 otherwise unchanged. Please pull. Thanks. On Tue, 29 Aug 2017, Nicolas Pitre wrote: > Russell, could you please pull the following: > > http://git.linaro.org/people/nicolas.pitre/linux fdpic > > This series provides the needed changes to suport the ELF_FDPIC binary > format on ARM. Both MMU and non-MMU systems are supported. This format > has many advantages over the BFLT format used on MMU-less systems, such > as being real ELF that can be parsed by standard tools, can support > shared dynamic libs, etc. > > This is based on v4.13-rc4 not to conflict with changes to signal.c > that happened in v4.13-rc3. > > A complete toolchain and prebuilt packages can be obtained here: > > https://github.com/mickael-guene/fdpic_manifest > > Changes from v1: > > - Reworked the signal return code to be compatible with a non-executable > stack. > - Rebased on v4.13-rc4 to pick up latest signal changes. > - Added MMU support. > - Fixed crash in the ELF-FDPIC loader when loading an executable with > shared libs on a system with an MMU. > - Made the regular ELF loader reject FDPIC binaries. > - Added ACKs and Reviewed-bys. > > diffstat: > > arch/arm/include/asm/elf.h | 16 +++++++-- > arch/arm/include/asm/mmu.h | 8 +++++ > arch/arm/include/asm/processor.h | 22 +++++++++---- > arch/arm/include/asm/ucontext.h | 1 + > arch/arm/include/uapi/asm/ptrace.h | 4 +++ > arch/arm/include/uapi/asm/unistd.h | 1 + > arch/arm/kernel/asm-offsets.c | 4 +++ > arch/arm/kernel/elf.c | 24 +++++++++++++- > arch/arm/kernel/signal.c | 53 +++++++++++++++++++++--------- > arch/arm/kernel/signal.h | 11 +++++++ > arch/arm/kernel/sigreturn_codes.S | 56 +++++++++++++++++++++++++++++--- > arch/arm/kernel/traps.c | 3 ++ > fs/Kconfig.binfmt | 4 +-- > fs/binfmt_elf.c | 15 +++++++-- > fs/binfmt_elf_fdpic.c | 13 ++++++-- > 15 files changed, 199 insertions(+), 36 deletions(-) > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PULL REQUEST v2] FDPIC ELF support for ARM 2017-08-30 3:16 [PULL REQUEST v2] FDPIC ELF support for ARM Nicolas Pitre 2017-09-19 21:14 ` Nicolas Pitre @ 2020-06-08 22:47 ` Russell King - ARM Linux admin 2020-06-09 3:48 ` Nicolas Pitre 1 sibling, 1 reply; 6+ messages in thread From: Russell King - ARM Linux admin @ 2020-06-08 22:47 UTC (permalink / raw) To: Nicolas Pitre, David Howells, Alexander Viro; +Cc: linux-arm-kernel Nico, Al Viro has identified this in include/uapi/linux/elfcore.h: elf_gregset_t pr_reg; /* GP registers */ #ifdef CONFIG_BINFMT_ELF_FDPIC /* When using FDPIC, the loadmap addresses need to be communicated * to GDB in order for GDB to do the necessary relocations. The * fields (below) used to communicate this information are placed * immediately after ``pr_reg'', so that the loadmap addresses may * be viewed as part of the register set if so desired. */ unsigned long pr_exec_fdpic_loadmap; unsigned long pr_interp_fdpic_loadmap; #endif int pr_fpvalid; /* True if math co-processor being used. */ which means if CONFIG_BINFMT_ELF_FDPIC is enabled for a target that also uses ELF, then the ELF coredump format breaks. David Howells says this evening: 23:42 < dhowells> you weren't meant to use ELF and ELF_FDPIC both So, we now have a problem; your code has done something that was never intended to be permitted, and there are configurations where the kernel breaks the user API. This only affects ARM as this is the only arch that was silly enough to allow ELF and ELF_FDPIC. Please address. Thanks. On Tue, Aug 29, 2017 at 11:16:13PM -0400, Nicolas Pitre wrote: > Russell, could you please pull the following: > > http://git.linaro.org/people/nicolas.pitre/linux fdpic > > This series provides the needed changes to suport the ELF_FDPIC binary > format on ARM. Both MMU and non-MMU systems are supported. This format > has many advantages over the BFLT format used on MMU-less systems, such > as being real ELF that can be parsed by standard tools, can support > shared dynamic libs, etc. > > This is based on v4.13-rc4 not to conflict with changes to signal.c > that happened in v4.13-rc3. > > A complete toolchain and prebuilt packages can be obtained here: > > https://github.com/mickael-guene/fdpic_manifest > > Changes from v1: > > - Reworked the signal return code to be compatible with a non-executable > stack. > - Rebased on v4.13-rc4 to pick up latest signal changes. > - Added MMU support. > - Fixed crash in the ELF-FDPIC loader when loading an executable with > shared libs on a system with an MMU. > - Made the regular ELF loader reject FDPIC binaries. > - Added ACKs and Reviewed-bys. > > diffstat: > > arch/arm/include/asm/elf.h | 16 +++++++-- > arch/arm/include/asm/mmu.h | 8 +++++ > arch/arm/include/asm/processor.h | 22 +++++++++---- > arch/arm/include/asm/ucontext.h | 1 + > arch/arm/include/uapi/asm/ptrace.h | 4 +++ > arch/arm/include/uapi/asm/unistd.h | 1 + > arch/arm/kernel/asm-offsets.c | 4 +++ > arch/arm/kernel/elf.c | 24 +++++++++++++- > arch/arm/kernel/signal.c | 53 +++++++++++++++++++++--------- > arch/arm/kernel/signal.h | 11 +++++++ > arch/arm/kernel/sigreturn_codes.S | 56 +++++++++++++++++++++++++++++--- > arch/arm/kernel/traps.c | 3 ++ > fs/Kconfig.binfmt | 4 +-- > fs/binfmt_elf.c | 15 +++++++-- > fs/binfmt_elf_fdpic.c | 13 ++++++-- > 15 files changed, 199 insertions(+), 36 deletions(-) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 503kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PULL REQUEST v2] FDPIC ELF support for ARM 2020-06-08 22:47 ` Russell King - ARM Linux admin @ 2020-06-09 3:48 ` Nicolas Pitre 2020-06-09 4:19 ` Al Viro 2020-06-09 8:06 ` David Howells 0 siblings, 2 replies; 6+ messages in thread From: Nicolas Pitre @ 2020-06-09 3:48 UTC (permalink / raw) To: Russell King - ARM Linux admin Cc: David Howells, Alexander Viro, linux-arm-kernel On Mon, 8 Jun 2020, Russell King - ARM Linux admin wrote: > Nico, > > Al Viro has identified this in include/uapi/linux/elfcore.h: > > elf_gregset_t pr_reg; /* GP registers */ > #ifdef CONFIG_BINFMT_ELF_FDPIC > /* When using FDPIC, the loadmap addresses need to be communicated > * to GDB in order for GDB to do the necessary relocations. The > * fields (below) used to communicate this information are placed > * immediately after ``pr_reg'', so that the loadmap addresses may > * be viewed as part of the register set if so desired. > */ > unsigned long pr_exec_fdpic_loadmap; > unsigned long pr_interp_fdpic_loadmap; > #endif > int pr_fpvalid; /* True if math co-processor being used. */ > > which means if CONFIG_BINFMT_ELF_FDPIC is enabled for a target that > also uses ELF, then the ELF coredump format breaks. Damn... indeed. > David Howells says this evening: > > 23:42 < dhowells> you weren't meant to use ELF and ELF_FDPIC both > > So, we now have a problem; your code has done something that was never > intended to be permitted, and there are configurations where the kernel > breaks the user API. This only affects ARM as this is the only arch > that was silly enough to allow ELF and ELF_FDPIC. Well... of course it could also be silly to run gdb on ELF_FDPIC-only systems as such systems are expected to have highly constrained resources. So a typical use case would consist in developing ELF_FDPIC binaries on a regular ELF host (handy as they can be tested natively) and possibly using gdb on them. So IMHO not having foreseen simultaneous usage of ELF and ELF_FDPIC here is rather unfortunate. I suspect riscv will end up in the same situation when they upstream their fdpic support. Admitedly I'm not a huge gdb user and didn't look closely at the existing coredump interface details when I enabled ELF_FDPIC on ARM. This is all generic architecture-independent code so it ought to "just work", right? So here's how I think this could be "fixed". This is not ideal. The fdpic support in Arm gdb would have to cope, but I doubt this is going to affect a lot of people without the knowledge to figure things out. If someone has a better idea/suggestion please say so. diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index 240f666635..3005a97fe1 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -1339,7 +1339,7 @@ static inline void fill_note(struct memelfnote *note, const char *name, int type * fill up all the fields in prstatus from the given task struct, except * registers which need to be filled up separately. */ -static void fill_prstatus(struct elf_prstatus *prstatus, +static void fill_prstatus(struct elf_fdpic_prstatus *prstatus, struct task_struct *p, long signr) { prstatus->pr_info.si_signo = prstatus->pr_cursig = signr; @@ -1422,7 +1422,7 @@ static int fill_psinfo(struct elf_prpsinfo *psinfo, struct task_struct *p, struct elf_thread_status { struct list_head list; - struct elf_prstatus prstatus; /* NT_PRSTATUS */ + struct elf_fdpic_prstatus prstatus; /* NT_PRSTATUS */ elf_fpregset_t fpu; /* NT_PRFPREG */ struct task_struct *thread; #ifdef ELF_CORE_COPY_XFPREGS @@ -1557,7 +1557,7 @@ static int elf_fdpic_core_dump(struct coredump_params *cprm) loff_t offset = 0, dataoff; int numnote; struct memelfnote *notes = NULL; - struct elf_prstatus *prstatus = NULL; /* NT_PRSTATUS */ + struct elf_fdpic_prstatus *prstatus = NULL; /* NT_PRSTATUS */ struct elf_prpsinfo *psinfo = NULL; /* NT_PRPSINFO */ LIST_HEAD(thread_list); struct list_head *t; diff --git a/include/uapi/linux/elfcore.h b/include/uapi/linux/elfcore.h index baf0356230..501658a007 100644 --- a/include/uapi/linux/elfcore.h +++ b/include/uapi/linux/elfcore.h @@ -61,8 +61,27 @@ struct elf_prstatus long pr_instr; /* Current instruction */ #endif elf_gregset_t pr_reg; /* GP registers */ + int pr_fpvalid; /* True if math co-processor being used. */ +}; + #ifdef CONFIG_BINFMT_ELF_FDPIC - /* When using FDPIC, the loadmap addresses need to be communicated +struct elf_fdpic_prstatus +{ + struct elf_siginfo pr_info; /* Info associated with signal */ + short pr_cursig; /* Current signal */ + unsigned long pr_sigpend; /* Set of pending signals */ + unsigned long pr_sighold; /* Set of held signals */ + pid_t pr_pid; + pid_t pr_ppid; + pid_t pr_pgrp; + pid_t pr_sid; + struct __kernel_old_timeval pr_utime; /* User time */ + struct __kernel_old_timeval pr_stime; /* System time */ + struct __kernel_old_timeval pr_cutime; /* Cumulative user time */ + struct __kernel_old_timeval pr_cstime; /* Cumulative system time */ + elf_gregset_t pr_reg; /* GP registers */ + /* + * When using FDPIC, the loadmap addresses need to be communicated * to GDB in order for GDB to do the necessary relocations. The * fields (below) used to communicate this information are placed * immediately after ``pr_reg'', so that the loadmap addresses may @@ -70,9 +89,9 @@ struct elf_prstatus */ unsigned long pr_exec_fdpic_loadmap; unsigned long pr_interp_fdpic_loadmap; -#endif int pr_fpvalid; /* True if math co-processor being used. */ }; +#endif #define ELF_PRARGSZ (80) /* Number of chars for args */ @@ -92,7 +111,18 @@ struct elf_prpsinfo }; #ifndef __KERNEL__ +#if defined(CONFIG_BINFMT_ELF_FDPIC) && \ + (defined(CONFIG_SUPERH32) || defined(CONFIG_C6X)) +/* + * This is to be backward compatible with those architectures that + * traditionally don't have both ELF and ELF_FDPIC configured at the same + * time and that expect prstatus_t to contain pr_exec_fdpic_loadmap and + * pr_exec_fdpic_loadmap. + */ +typedef struct elf_fdpic_prstatus prstatus_t; +#else typedef struct elf_prstatus prstatus_t; +#endif typedef struct elf_prpsinfo prpsinfo_t; #define PRARGSZ ELF_PRARGSZ #endif _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PULL REQUEST v2] FDPIC ELF support for ARM 2020-06-09 3:48 ` Nicolas Pitre @ 2020-06-09 4:19 ` Al Viro 2020-06-09 8:06 ` David Howells 1 sibling, 0 replies; 6+ messages in thread From: Al Viro @ 2020-06-09 4:19 UTC (permalink / raw) To: Nicolas Pitre Cc: David Howells, Russell King - ARM Linux admin, linux-arm-kernel On Mon, Jun 08, 2020 at 11:48:27PM -0400, Nicolas Pitre wrote: > I suspect riscv will end up in the same situation when they upstream > their fdpic support. FWIW, one thing that needs to be done is switching fdpic to use of regset, a-la normal elf coredumps on the same arm. I really want to kill the sodding elf_core_copy_task_fpregs(), dump_fpu(), etc. Right now that crap is used by elf coredump on alpha c6x csky h8300 m68k microblaze nds32 um unicore32 fdpic coredump on arm sh/nommu and c6x Out of those only alpha, m68k, microblaze, um and unicore32 lack regset - everything else (including all users of fdpic) have working ones. And it's not at all hard to add the damn thing to those 5 architectures, killing quite bit of code in binfmt_elf.c, as well as in arch/* Note, BTW, that fdpic coredumps on arm currently have fucked FPU for all but the main thread - arm has int dump_fpu (struct pt_regs *regs, struct user_fp *fp) { struct thread_info *thread = current_thread_info(); int used_math = thread->used_cp[1] | thread->used_cp[2]; if (used_math) memcpy(fp, &thread->fpstate.soft, sizeof (*fp)); return used_math != 0; } which obviously duplicates the contents of FP registers of the coredumping thread into the NT_PRFPREG section for each thread... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PULL REQUEST v2] FDPIC ELF support for ARM 2020-06-09 3:48 ` Nicolas Pitre 2020-06-09 4:19 ` Al Viro @ 2020-06-09 8:06 ` David Howells 1 sibling, 0 replies; 6+ messages in thread From: David Howells @ 2020-06-09 8:06 UTC (permalink / raw) To: Nicolas Pitre Cc: dhowells, Russell King - ARM Linux admin, linux-arm-kernel, Alexander Viro Nicolas Pitre <nico@fluxnic.net> wrote: > Well... of course it could also be silly to run gdb on ELF_FDPIC-only > systems as such systems are expected to have highly constrained > resources. gdbserver and kgdb work. But on a NOMMU system, FDPIC allows for executable and library text segment and rodata segment sharing and you can't set breakpoints by instruction substitution in anything that's shared - uclibc, for example - so you have to be very careful. David _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-09 8:07 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-30 3:16 [PULL REQUEST v2] FDPIC ELF support for ARM Nicolas Pitre 2017-09-19 21:14 ` Nicolas Pitre 2020-06-08 22:47 ` Russell King - ARM Linux admin 2020-06-09 3:48 ` Nicolas Pitre 2020-06-09 4:19 ` Al Viro 2020-06-09 8:06 ` David Howells
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).