[PULL REQUEST v2] FDPIC ELF support for ARM

[PULL REQUEST v2] FDPIC ELF support for ARM

[Nicolas Pitre]

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(-)

[PULL REQUEST v2] FDPIC ELF support for ARM

[Nicolas Pitre]

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(-)
> 

Re: [PULL REQUEST v2] FDPIC ELF support for ARM

[Russell King - ARM Linux admin]

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

Re: [PULL REQUEST v2] FDPIC ELF support for ARM

[Nicolas Pitre]

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

Re: [PULL REQUEST v2] FDPIC ELF support for ARM

[Al Viro]

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

Re: [PULL REQUEST v2] FDPIC ELF support for ARM

[David Howells]

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