riscv: support ELF format binaries in nommu mode

PATCH Applied Greg Ungerer 4 participants 12 messages Jul 11, 2023 – Aug 30, 2023

Subsystems (4)

Memory management VFS RISC-V exec and binfmt

lore

Share & tools

lore

Greg Ungerer

author

2023-07-11 13:08 UTC #0 lore raw

v2 cover riscv: support ELF format binaries in nommu mode

The following changes add the ability to run ELF format binaries when running RISC-V in nommu mode. That support is actually part of the ELF-FDPIC loader, so these changes are all about making that work on RISC-V.

The first issue to deal with is making the ELF-FDPIC loader capable of handling 64-bit ELF files. As coded right now it only supports 32-bit ELF files.

Secondly some changes are required to enable and compile the ELF-FDPIC loader on RISC-V and to pass the ELF-FDPIC mapping addresses through to user space when execing the new program.

These changes have not been used to run actual ELF-FDPIC binaries. It is used to load and run normal ELF - compiled -pie format. Though the underlying changes are expected to work with full ELF-FDPIC binaries if or when that is supported on RISC-V in gcc.

To avoid needing changes to the C-library (tested with uClibc-ng currently) there is a simple runtime dynamic loader (interpreter) available to do the final relocations, https://github.com/gregungerer/uldso.
The nice thing about doing it this way is that the same program binary can also be loaded with the usual ELF loader in MMU linux.

The motivation here is to provide an easy to use alternative to the flat format binaries normally used for RISC-V nommu based systems.

Signed-off-by Greg Ungerer <[email protected]>

---
v1->v2: rebase onto 6.5-rc1

 arch/riscv/include/asm/elf.h         |   11 +++++++++-
 arch/riscv/include/asm/mmu.h         |    4 +++
 arch/riscv/include/uapi/asm/ptrace.h |    5 ++++
 fs/Kconfig.binfmt                    |    2 -
 fs/binfmt_elf_fdpic.c                |   38 +++++++++++++++++------------------
 include/linux/elf-fdpic.h            |   14 +++++++++++-
 include/uapi/linux/elf-fdpic.h       |   15 +++++++++++++
 7 files changed, 67 insertions(+), 22 deletions(-)

Greg Ungerer

author

2023-07-11 13:08 UTC #1 lore raw

PATCH v2 1/2 binfmt_elf_fdpic: support 64-bit systems

The binfmt_flat_fdpic code has a number of 32-bit specific data structures associated with it. Extend it to be able to support and be used on 64-bit systems as well.

The new code defines a number of key 64-bit variants of the core elf-fdpic data structures - along side the existing 32-bit sized ones. A common set of generic named structures are defined to be either the 32-bit or 64-bit ones as required at compile time. This is a similar technique to that used in the ELF binfmt loader.

For example:

elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap

the choice based on ELFCLASS32 or ELFCLASS64.

Signed-off-by Greg Ungerer <[email protected]>

---
v1->v2: rebase onto linux-6.5-rc1

 fs/binfmt_elf_fdpic.c          | 38 +++++++++++++++++-----------------
 include/linux/elf-fdpic.h      | 14 ++++++++++++-
 include/uapi/linux/elf-fdpic.h | 15 ++++++++++++++
 3 files changed, 47 insertions(+), 20 deletions(-)

fs/binfmt_elf_fdpic.c +19 ~~-19~~

index 1c6c5832af86..43b2a2851ba3 100644
@@ -138,7 +138,7 @@ static int is_constdisp(struct elfhdr *hdr)
 static int elf_fdpic_fetch_phdrs(struct elf_fdpic_params *params,
 				 struct file *file)
 {
-	struct elf32_phdr *phdr;
+	struct elf_phdr *phdr;
 	unsigned long size;
 	int retval, loop;
 	loff_t pos = params->hdr.e_phoff;

@@ -560,8 +560,8 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
 	sp &= ~7UL;
 
 	/* stack the load map(s) */
-	len = sizeof(struct elf32_fdpic_loadmap);
-	len += sizeof(struct elf32_fdpic_loadseg) * exec_params->loadmap->nsegs;
+	len = sizeof(struct elf_fdpic_loadmap);
+	len += sizeof(struct elf_fdpic_loadseg) * exec_params->loadmap->nsegs;
 	sp = (sp - len) & ~7UL;
 	exec_params->map_addr = sp;

@@ -571,8 +571,8 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm,
 	current->mm->context.exec_fdpic_loadmap = (unsigned long) sp;
 
 	if (interp_params->loadmap) {
-		len = sizeof(struct elf32_fdpic_loadmap);
-		len += sizeof(struct elf32_fdpic_loadseg) *
+		len = sizeof(struct elf_fdpic_loadmap);
+		len += sizeof(struct elf_fdpic_loadseg) *
 			interp_params->loadmap->nsegs;
 		sp = (sp - len) & ~7UL;
 		interp_params->map_addr = sp;

@@ -740,13 +740,13 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params,
 			      struct mm_struct *mm,
 			      const char *what)
 {
-	struct elf32_fdpic_loadmap *loadmap;
+	struct elf_fdpic_loadmap *loadmap;
 #ifdef CONFIG_MMU
-	struct elf32_fdpic_loadseg *mseg;
+	struct elf_fdpic_loadseg *mseg;
 	unsigned long load_addr;
 #endif
-	struct elf32_fdpic_loadseg *seg;
-	struct elf32_phdr *phdr;
+	struct elf_fdpic_loadseg *seg;
+	struct elf_phdr *phdr;
 	unsigned nloads, tmp;
 	unsigned long stop;
 	int loop, ret;

@@ -766,7 +766,7 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params,
 
 	params->loadmap = loadmap;
 
-	loadmap->version = ELF32_FDPIC_LOADMAP_VERSION;
+	loadmap->version = ELF_FDPIC_LOADMAP_VERSION;
 	loadmap->nsegs = nloads;
 
 	/* map the requested LOADs into the memory space */

@@ -839,8 +839,8 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params,
 			if (phdr->p_vaddr >= seg->p_vaddr &&
 			    phdr->p_vaddr + phdr->p_memsz <=
 			    seg->p_vaddr + seg->p_memsz) {
-				Elf32_Dyn __user *dyn;
-				Elf32_Sword d_tag;
+				Elf_Dyn __user *dyn;
+				Elf_Sword d_tag;
 
 				params->dynamic_addr =
 					(phdr->p_vaddr - seg->p_vaddr) +

@@ -850,11 +850,11 @@ static int elf_fdpic_map_file(struct elf_fdpic_params *params,
 				 * one item, and that the last item is a NULL
 				 * entry */
 				if (phdr->p_memsz == 0 ||
-				    phdr->p_memsz % sizeof(Elf32_Dyn) != 0)
+				    phdr->p_memsz % sizeof(Elf_Dyn) != 0)
 					goto dynamic_error;
 
-				tmp = phdr->p_memsz / sizeof(Elf32_Dyn);
-				dyn = (Elf32_Dyn __user *)params->dynamic_addr;
+				tmp = phdr->p_memsz / sizeof(Elf_Dyn);
+				dyn = (Elf_Dyn __user *)params->dynamic_addr;
 				if (get_user(d_tag, &dyn[tmp - 1].d_tag) ||
 				    d_tag != 0)
 					goto dynamic_error;

@@ -923,8 +923,8 @@ static int elf_fdpic_map_file_constdisp_on_uclinux(
 	struct file *file,
 	struct mm_struct *mm)
 {
-	struct elf32_fdpic_loadseg *seg;
-	struct elf32_phdr *phdr;
+	struct elf_fdpic_loadseg *seg;
+	struct elf_phdr *phdr;
 	unsigned long load_addr, base = ULONG_MAX, top = 0, maddr = 0;
 	int loop, ret;

@@ -1007,8 +1007,8 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params,
 					     struct file *file,
 					     struct mm_struct *mm)
 {
-	struct elf32_fdpic_loadseg *seg;
-	struct elf32_phdr *phdr;
+	struct elf_fdpic_loadseg *seg;
+	struct elf_phdr *phdr;
 	unsigned long load_addr, delta_vaddr;
 	int loop, dvset;

include/linux/elf-fdpic.h +13 -1

index 3bea95a1af53..e533f4513194 100644
@@ -10,13 +10,25 @@
 
 #include <uapi/linux/elf-fdpic.h>
 
+#if ELF_CLASS == ELFCLASS32
+#define Elf_Sword			Elf32_Sword
+#define elf_fdpic_loadseg		elf32_fdpic_loadseg
+#define elf_fdpic_loadmap		elf32_fdpic_loadmap
+#define ELF_FDPIC_LOADMAP_VERSION	ELF32_FDPIC_LOADMAP_VERSION
+#else
+#define Elf_Sword			Elf64_Sxword
+#define elf_fdpic_loadmap		elf64_fdpic_loadmap
+#define elf_fdpic_loadseg		elf64_fdpic_loadseg
+#define ELF_FDPIC_LOADMAP_VERSION	ELF64_FDPIC_LOADMAP_VERSION
+#endif
+
 /*
  * binfmt binary parameters structure
  */
 struct elf_fdpic_params {
 	struct elfhdr			hdr;		/* ref copy of ELF header */
 	struct elf_phdr			*phdrs;		/* ref copy of PT_PHDR table */
-	struct elf32_fdpic_loadmap	*loadmap;	/* loadmap to be passed to userspace */
+	struct elf_fdpic_loadmap	*loadmap;	/* loadmap to be passed to userspace */
 	unsigned long			elfhdr_addr;	/* mapped ELF header user address */
 	unsigned long			ph_addr;	/* mapped PT_PHDR user address */
 	unsigned long			map_addr;	/* mapped loadmap user address */

include/uapi/linux/elf-fdpic.h +15 -0

index 4fcc6cfebe18..ec23f0871129 100644
@@ -32,4 +32,19 @@ struct elf32_fdpic_loadmap {
 
 #define ELF32_FDPIC_LOADMAP_VERSION	0x0000
 
+/* segment mappings for ELF FDPIC libraries/executables/interpreters */
+struct elf64_fdpic_loadseg {
+	Elf64_Addr	addr;		/* core address to which mapped */
+	Elf64_Addr	p_vaddr;	/* VMA recorded in file */
+	Elf64_Word	p_memsz;	/* allocation size recorded in file */
+};
+
+struct elf64_fdpic_loadmap {
+	Elf64_Half	version;	/* version of these structures, just in case... */
+	Elf64_Half	nsegs;		/* number of segments */
+	struct elf64_fdpic_loadseg segs[];
+};
+
+#define ELF64_FDPIC_LOADMAP_VERSION	0x0000
+
 #endif /* _UAPI_LINUX_ELF_FDPIC_H */

Signature · 7 lines

2.25.1


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Greg Ungerer

author

2023-07-11 13:08 UTC #3 lore raw

PATCH v2 2/2 riscv: support the elf-fdpic binfmt loader

In reply to Greg Ungerer

Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.

One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.

Signed-off-by Greg Ungerer <[email protected]>

---
v1->v2: rebase onto linux-6.5-rc1
increment PTRACE_GETFDPIC value to keep it unique

 arch/riscv/include/asm/elf.h         | 11 ++++++++++-
 arch/riscv/include/asm/mmu.h         |  4 ++++
 arch/riscv/include/uapi/asm/ptrace.h |  5 +++++
 fs/Kconfig.binfmt                    |  2 +-
 4 files changed, 20 insertions(+), 2 deletions(-)

arch/riscv/include/asm/elf.h +10 -1

index c24280774caf..c33fe923ef6d 100644
@@ -41,6 +41,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
 #define compat_elf_check_arch	compat_elf_check_arch
 
 #define CORE_DUMP_USE_REGSET
+#define ELF_FDPIC_CORE_EFLAGS	0
 #define ELF_EXEC_PAGESIZE	(PAGE_SIZE)
 
 /*

@@ -69,6 +70,13 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
 #define ELF_HWCAP	riscv_get_elf_hwcap()
 extern unsigned long elf_hwcap;
 
+#define ELF_FDPIC_PLAT_INIT(_r, _exec_map_addr, _interp_map_addr, dynamic_addr) \
+	do { \
+		(_r)->a1 = _exec_map_addr; \
+		(_r)->a2 = _interp_map_addr; \
+		(_r)->a3 = dynamic_addr; \
+	} while (0)
+
 /*
  * This yields a string that ld.so will use to load implementation
  * specific libraries for optimization.  This is more specific in

@@ -78,7 +86,6 @@ extern unsigned long elf_hwcap;
 
 #define COMPAT_ELF_PLATFORM	(NULL)
 
-#ifdef CONFIG_MMU
 #define ARCH_DLINFO						\
 do {								\
 	/*							\

@@ -115,6 +122,8 @@ do {								\
 	else							 \
 		NEW_AUX_ENT(AT_IGNORE, 0);			 \
 } while (0)
+
+#ifdef CONFIG_MMU
 #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
 struct linux_binprm;
 extern int arch_setup_additional_pages(struct linux_binprm *bprm,

arch/riscv/include/asm/mmu.h +4 -0

index 0099dc116168..355504b37f8e 100644
@@ -20,6 +20,10 @@ typedef struct {
 	/* A local icache flush is needed before user execution can resume. */
 	cpumask_t icache_stale_mask;
 #endif
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+	unsigned long exec_fdpic_loadmap;
+	unsigned long interp_fdpic_loadmap;
+#endif
 } mm_context_t;
 
 void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t pa,

arch/riscv/include/uapi/asm/ptrace.h +5 -0

index e17c550986a6..30f6d6537adc 100644
@@ -10,6 +10,11 @@
 
 #include <linux/types.h>
 
+#define PTRACE_GETFDPIC		33
+
+#define PTRACE_GETFDPIC_EXEC	0
+#define PTRACE_GETFDPIC_INTERP	1
+
 /*
  * User-mode register state for core dumps, ptrace, sigcontext
  *

fs/Kconfig.binfmt +1 -1

index 93539aac0e5b..f5693164ca9a 100644
@@ -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 || SUPERH || 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

Signature · 1 line

2.25.1

Kees Cook

Acked-by on v2 1/2

2023-07-11 15:51 UTC #2 lore raw

Re: [PATCH v2 1/2] binfmt_elf_fdpic: support 64-bit systems

In reply to Greg Ungerer

Quoted 10 lines · Greg Ungerer

The binfmt_flat_fdpic code has a number of 32-bit specific data structures associated with it. Extend it to be able to support and be used on 64-bit systems as well.
The new code defines a number of key 64-bit variants of the core elf-fdpic data structures - along side the existing 32-bit sized ones. A common set of generic named structures are defined to be either the 32-bit or 64-bit ones as required at compile time. This is a similar technique to that used in the ELF binfmt loader.

Quoted 8 lines

For example:
elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap
the choice based on ELFCLASS32 or ELFCLASS64.
Signed-off-by Greg Ungerer <[email protected]>

This looks good an is consistent with what the regular ELF loader does with the sized types.

Acked-by Kees Cook <[email protected]>

Signature · 1 line

Kees Cook

Kees Cook

Acked-by on v2 2/2

2023-07-11 15:54 UTC #4 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

In reply to Greg Ungerer

Quoted 9 lines · Greg Ungerer

Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>

ELF stuff looks fine to me. If the RISC-V folks are happy with the rest, this looks good.

Acked-by Kees Cook <[email protected]>

Please feel free to carry this in the RISC-V tree. If you'd rather it go via execve tree, please let me know. :)

-Kees

Signature · 1 line

Kees Cook

Greg Ungerer

author

2023-07-12 01:42 UTC #5 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

Hi Kees,

Quoted 11 lines · Kees Cook

Quoted 9 lines · Greg Ungerer
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>

Quoted 7 lines

ELF stuff looks fine to me. If the RISC-V folks are happy with the rest, this looks good.
Acked-by Kees Cook <[email protected]>
Please feel free to carry this in the RISC-V tree. If you'd rather it go via execve tree, please let me know. :)

Thanks for the feedback, much appreciated!

Regards
Greg

Stefan O'Rear

2023-07-12 15:13 UTC #6 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

In reply to Greg Ungerer

Quoted 33 lines · Greg Ungerer

Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>
---
v1->v2: rebase onto linux-6.5-rc1
increment PTRACE_GETFDPIC value to keep it unique
 arch/riscv/include/asm/elf.h         | 11 ++++++++++-
 arch/riscv/include/asm/mmu.h         |  4 ++++
 arch/riscv/include/uapi/asm/ptrace.h |  5 +++++
 fs/Kconfig.binfmt                    |  2 +-
 4 files changed, 20 insertions(+), 2 deletions(-)
arch/riscv/include/asm/elf.h +1 -0
index c24280774caf..c33fe923ef6d 100644
@@ -41,6 +41,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
 #define compat_elf_check_arch	compat_elf_check_arch
 
 #define CORE_DUMP_USE_REGSET
+#define ELF_FDPIC_CORE_EFLAGS	0
 #define ELF_EXEC_PAGESIZE	(PAGE_SIZE)
 
 /*
@@ -69,6 +70,13 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
 #define ELF_HWCAP	riscv_get_elf_hwcap()

arch/riscv/include/asm/elf.h extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); · line 80

Quoted 10 lines

arch/riscv/include/asm/elf.h +7 -0

 extern unsigned long elf_hwcap;
 
+#define ELF_FDPIC_PLAT_INIT(_r, _exec_map_addr, _interp_map_addr, 
 dynamic_addr) \
+	do { \
+		(_r)->a1 = _exec_map_addr; \
+		(_r)->a2 = _interp_map_addr; \
+		(_r)->a3 = dynamic_addr; \
+	} while (0)
+

This should probably be left empty for now; it will be defined by the ELF FDPIC ABI when that is done, and shouldn't be used by normal ELF binaries. I'd ask if there's a reason it starts at a1 instead of a0, but it seems idiosyncratic on all arches that have full FDPIC support.

-s

Quoted 74 lines

arch/riscv/include/asm/elf.h +0 -0

 /*
  * This yields a string that ld.so will use to load implementation

* specific libraries for optimization. This is more specific in

arch/riscv/include/asm/elf.h +2 -1

@@ -78,7 +86,6 @@ extern unsigned long elf_hwcap;
 
 #define COMPAT_ELF_PLATFORM	(NULL)
 
-#ifdef CONFIG_MMU
 #define ARCH_DLINFO						\
 do {								\
 	/*							\

@@ -115,6 +122,8 @@ do {								\
 	else							 \
 		NEW_AUX_ENT(AT_IGNORE, 0);			 \
 } while (0)
+
+#ifdef CONFIG_MMU
 #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
 struct linux_binprm;
 extern int arch_setup_additional_pages(struct linux_binprm *bprm,

arch/riscv/include/asm/mmu.h +4 -0

index 0099dc116168..355504b37f8e 100644
@@ -20,6 +20,10 @@ typedef struct {
 	/* A local icache flush is needed before user execution can resume. */
 	cpumask_t icache_stale_mask;
 #endif
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+	unsigned long exec_fdpic_loadmap;
+	unsigned long interp_fdpic_loadmap;
+#endif
 } mm_context_t;
 
 void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t

pa,

arch/riscv/include/uapi/asm/ptrace.h +5 -0

index e17c550986a6..30f6d6537adc 100644
@@ -10,6 +10,11 @@
 
 #include <linux/types.h>
 
+#define PTRACE_GETFDPIC		33
+
+#define PTRACE_GETFDPIC_EXEC	0
+#define PTRACE_GETFDPIC_INTERP	1
+
 /*
  * User-mode register state for core dumps, ptrace, sigcontext
  *

fs/Kconfig.binfmt +1 -1

index 93539aac0e5b..f5693164ca9a 100644
@@ -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 || SUPERH || 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

Signature · 7 lines

2.25.1


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Greg Ungerer

author

2023-07-13 13:17 UTC #7 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

Quoted 36 lines · Stefan O'Rear

Quoted 35 lines · Greg Ungerer
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>
---
v1->v2: rebase onto linux-6.5-rc1
increment PTRACE_GETFDPIC value to keep it unique
  arch/riscv/include/asm/elf.h         | 11 ++++++++++-
  arch/riscv/include/asm/mmu.h         |  4 ++++
  arch/riscv/include/uapi/asm/ptrace.h |  5 +++++
  fs/Kconfig.binfmt                    |  2 +-
  4 files changed, 20 insertions(+), 2 deletions(-)
arch/riscv/include/asm/elf.h +1 -0
index c24280774caf..c33fe923ef6d 100644
@@ -41,6 +41,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
  #define compat_elf_check_arch	compat_elf_check_arch
 
  #define CORE_DUMP_USE_REGSET
+#define ELF_FDPIC_CORE_EFLAGS	0
  #define ELF_EXEC_PAGESIZE	(PAGE_SIZE)
 
  /*
@@ -69,6 +70,13 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
  #define ELF_HWCAP	riscv_get_elf_hwcap()
  extern unsigned long elf_hwcap;
 

Quoted 12 lines

arch/riscv/include/asm/elf.h extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); · line 79
Quoted 8 lines
arch/riscv/include/asm/elf.h +7 -0
+#define ELF_FDPIC_PLAT_INIT(_r, _exec_map_addr, _interp_map_addr,
 dynamic_addr) \
+	do { \
+		(_r)->a1 = _exec_map_addr; \
+		(_r)->a2 = _interp_map_addr; \
+		(_r)->a3 = dynamic_addr; \
+	} while (0)
+
This should probably be left empty for now; it will be defined by the ELF FDPIC ABI when that is done, and shouldn't be used by normal ELF binaries.

True, not used by the ELF binaries themselves. But used by an ELF interpreter to do the runtime relocations.

Quoted 2 lines

I'd ask if there's a reason it starts at a1 instead of a0, but it seems idiosyncratic on all arches that have full FDPIC support.

This comment in the crt1.S code of uClibc made me think that a0 already had a pre-defined use in the ABI:

/* The entry point's job is to call __uClibc_main. Per the ABI,
a0 contains the address of a function to be passed to atexit.

But I didn't dig any further than that.

Regards
Greg

Quoted 76 lines

-s

Quoted 74 lines

arch/riscv/include/asm/elf.h +0 -0

  /*
   * This yields a string that ld.so will use to load implementation

* specific libraries for optimization. This is more specific in

arch/riscv/include/asm/elf.h +2 -1

@@ -78,7 +86,6 @@ extern unsigned long elf_hwcap;
 
  #define COMPAT_ELF_PLATFORM	(NULL)
 
-#ifdef CONFIG_MMU
  #define ARCH_DLINFO						\
  do {								\
  	/*							\

@@ -115,6 +122,8 @@ do {								\
  	else							 \
  		NEW_AUX_ENT(AT_IGNORE, 0);			 \
  } while (0)
+
+#ifdef CONFIG_MMU
  #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
  struct linux_binprm;
  extern int arch_setup_additional_pages(struct linux_binprm *bprm,

arch/riscv/include/asm/mmu.h +4 -0

index 0099dc116168..355504b37f8e 100644
@@ -20,6 +20,10 @@ typedef struct {
  	/* A local icache flush is needed before user execution can resume. */
  	cpumask_t icache_stale_mask;
  #endif
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+	unsigned long exec_fdpic_loadmap;
+	unsigned long interp_fdpic_loadmap;
+#endif
  } mm_context_t;
 
  void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t

pa,

arch/riscv/include/uapi/asm/ptrace.h +5 -0

index e17c550986a6..30f6d6537adc 100644
@@ -10,6 +10,11 @@
 
  #include <linux/types.h>
 
+#define PTRACE_GETFDPIC		33
+
+#define PTRACE_GETFDPIC_EXEC	0
+#define PTRACE_GETFDPIC_INTERP	1
+
  /*
   * User-mode register state for core dumps, ptrace, sigcontext
   *

fs/Kconfig.binfmt +1 -1

index 93539aac0e5b..f5693164ca9a 100644
@@ -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 || SUPERH || 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

Signature · 7 lines

2.25.1


_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Stefan O'Rear

2023-07-13 14:26 UTC #8 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

Quoted 50 lines · Greg Ungerer

Quoted 36 lines · Stefan O'Rear
Quoted 35 lines · Greg Ungerer
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>
---
v1->v2: rebase onto linux-6.5-rc1
increment PTRACE_GETFDPIC value to keep it unique
  arch/riscv/include/asm/elf.h         | 11 ++++++++++-
  arch/riscv/include/asm/mmu.h         |  4 ++++
  arch/riscv/include/uapi/asm/ptrace.h |  5 +++++
  fs/Kconfig.binfmt                    |  2 +-
  4 files changed, 20 insertions(+), 2 deletions(-)
arch/riscv/include/asm/elf.h +1 -0
index c24280774caf..c33fe923ef6d 100644
@@ -41,6 +41,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
  #define compat_elf_check_arch	compat_elf_check_arch
 
  #define CORE_DUMP_USE_REGSET
+#define ELF_FDPIC_CORE_EFLAGS	0
  #define ELF_EXEC_PAGESIZE	(PAGE_SIZE)
 
  /*
@@ -69,6 +70,13 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
  #define ELF_HWCAP	riscv_get_elf_hwcap()
  extern unsigned long elf_hwcap;
 
Quoted 12 lines
arch/riscv/include/asm/elf.h extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); · line 79
Quoted 8 lines
arch/riscv/include/asm/elf.h +7 -0
+#define ELF_FDPIC_PLAT_INIT(_r, _exec_map_addr, _interp_map_addr,
 dynamic_addr) \
+	do { \
+		(_r)->a1 = _exec_map_addr; \
+		(_r)->a2 = _interp_map_addr; \
+		(_r)->a3 = dynamic_addr; \
+	} while (0)
+
This should probably be left empty for now; it will be defined by the ELF FDPIC ABI when that is done, and shouldn't be used by normal ELF binaries.

Quoted 2 lines

True, not used by the ELF binaries themselves. But used by an ELF interpreter to do the runtime relocations.

By "normal ELF binaries", I mean binaries (executables and shared libraries with nonzero e_entry, including statically linked binaries and the dynamic linker itself) that conform to the psABI as it currently exists in riscv-elf-psabi-doc.

These binaries don't use load maps because they aren't defined in riscv-elf-psabi-doc yet. At some point in the future, riscv-elf-psabi-doc may define a FDPIC EI_OSABI value and rules for its usage; "FDPIC ELF binaries" will not be "normal" and you will not be able to load them with binfmt_elf or binfmt_elf_compat.

"FDPIC elf binaries" which contain their own self-relocation code, including the dynamic linker and statically linked binaries, will use the map and dynamic addresses.

elf_check_fdpic will return 1 for binaries that use the FDPIC EI_OSABI and use the load maps as part of either their own or their interpreter's startup code. For binaries where elf_check_fdpic returns 0, the contents of ELF_FDPIC_PLAT_INIT is (harmless) dead stores.

We don't have an implementation of elf_check_fdpic yet, which means that we cannot load binaries that actually use the load maps and the ELF_FDPIC_PLAT_INIT is dead code. Dead code which is unlikely to conform to the future ABI, since the RISC-V psABI Task Group has yet to choose which registers to use to pass the load maps. Since the code is dead and likely wrong, it should be removed so that correct code can be added at the correct time.

-s

Quoted 96 lines

Quoted 2 lines
I'd ask if there's a reason it starts at a1 instead of a0, but it seems idiosyncratic on all arches that have full FDPIC support.
This comment in the crt1.S code of uClibc made me think that a0 already had a pre-defined use in the ABI:
/* The entry point's job is to call __uClibc_main. Per the ABI,
a0 contains the address of a function to be passed to atexit.
But I didn't dig any further than that.
Regards
Greg
Quoted 72 lines
-s
Quoted 70 lines
arch/riscv/include/asm/elf.h +0 -0
  /*
   * This yields a string that ld.so will use to load implementation
* specific libraries for optimization. This is more specific in
arch/riscv/include/asm/elf.h +2 -1
@@ -78,7 +86,6 @@ extern unsigned long elf_hwcap;
 
  #define COMPAT_ELF_PLATFORM	(NULL)
 
-#ifdef CONFIG_MMU
  #define ARCH_DLINFO						\
  do {								\
  	/*							\
@@ -115,6 +122,8 @@ do {								\
  	else							 \
  		NEW_AUX_ENT(AT_IGNORE, 0);			 \
  } while (0)
+
+#ifdef CONFIG_MMU
  #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
  struct linux_binprm;
  extern int arch_setup_additional_pages(struct linux_binprm *bprm,
arch/riscv/include/asm/mmu.h +4 -0
index 0099dc116168..355504b37f8e 100644
@@ -20,6 +20,10 @@ typedef struct {
  	/* A local icache flush is needed before user execution can resume. */
  	cpumask_t icache_stale_mask;
  #endif
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+	unsigned long exec_fdpic_loadmap;
+	unsigned long interp_fdpic_loadmap;
+#endif
  } mm_context_t;
 
  void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t
pa,
arch/riscv/include/uapi/asm/ptrace.h +5 -0
index e17c550986a6..30f6d6537adc 100644
@@ -10,6 +10,11 @@
 
  #include <linux/types.h>
 
+#define PTRACE_GETFDPIC		33
+
+#define PTRACE_GETFDPIC_EXEC	0
+#define PTRACE_GETFDPIC_INTERP	1
+
  /*
   * User-mode register state for core dumps, ptrace, sigcontext
   *
fs/Kconfig.binfmt +1 -1
index 93539aac0e5b..f5693164ca9a 100644
@@ -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 || SUPERH || 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
Signature · 1 line
2.25.1
Quoted 4 lines
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Greg Ungerer

author

2023-07-14 13:51 UTC #9 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

Quoted 65 lines · Stefan O'Rear

Quoted 50 lines · Greg Ungerer
Quoted 36 lines · Stefan O'Rear
Quoted 35 lines · Greg Ungerer
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>
---
v1->v2: rebase onto linux-6.5-rc1
increment PTRACE_GETFDPIC value to keep it unique
   arch/riscv/include/asm/elf.h         | 11 ++++++++++-
   arch/riscv/include/asm/mmu.h         |  4 ++++
   arch/riscv/include/uapi/asm/ptrace.h |  5 +++++
   fs/Kconfig.binfmt                    |  2 +-
   4 files changed, 20 insertions(+), 2 deletions(-)
arch/riscv/include/asm/elf.h +1 -0
index c24280774caf..c33fe923ef6d 100644
@@ -41,6 +41,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
   #define compat_elf_check_arch	compat_elf_check_arch
 
   #define CORE_DUMP_USE_REGSET
+#define ELF_FDPIC_CORE_EFLAGS	0
   #define ELF_EXEC_PAGESIZE	(PAGE_SIZE)
 
   /*
@@ -69,6 +70,13 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
   #define ELF_HWCAP	riscv_get_elf_hwcap()
   extern unsigned long elf_hwcap;
 
Quoted 12 lines
arch/riscv/include/asm/elf.h extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); · line 79
Quoted 8 lines
arch/riscv/include/asm/elf.h +7 -0
+#define ELF_FDPIC_PLAT_INIT(_r, _exec_map_addr, _interp_map_addr,
 dynamic_addr) \
+	do { \
+		(_r)->a1 = _exec_map_addr; \
+		(_r)->a2 = _interp_map_addr; \
+		(_r)->a3 = dynamic_addr; \
+	} while (0)
+
This should probably be left empty for now; it will be defined by the ELF FDPIC ABI when that is done, and shouldn't be used by normal ELF binaries.
Quoted 2 lines
True, not used by the ELF binaries themselves. But used by an ELF interpreter to do the runtime relocations.
By "normal ELF binaries", I mean binaries (executables and shared libraries with nonzero e_entry, including statically linked binaries and the dynamic linker itself) that conform to the psABI as it currently exists in riscv-elf-psabi-doc.
These binaries don't use load maps because they aren't defined in riscv-elf-psabi-doc yet. At some point in the future, riscv-elf-psabi-doc may define a FDPIC EI_OSABI value and rules for its usage; "FDPIC ELF binaries" will not be "normal" and you will not be able to load them with binfmt_elf or binfmt_elf_compat.

Quoted 3 lines

"FDPIC elf binaries" which contain their own self-relocation code, including the dynamic linker and statically linked binaries, will use the map and dynamic addresses.

Well, yes, none of that is specific to RISC-V though. Those same rules apply to FDPIC binaries on any architecture that supports it. FDPIC binaries can only be loaded by binfmt_elf_fdpic.

The point I was trying to make is that with a normal ELF binary (with obvious limitations in the noMMU case - needs to be PIE, and not using shared libraries, etc) if those mappings are present a specially crafted ELF interpreter can use them to carry out the relocations and start that ELF binary. That ELF binary is not special and can be loaded and run by the the standard binfmt_elf ELF loader on an a fully MMU system (of course using the usual ELF interpreter on that system not the different noMMU one).

Quoted 4 lines

elf_check_fdpic will return 1 for binaries that use the FDPIC EI_OSABI and use the load maps as part of either their own or their interpreter's startup code. For binaries where elf_check_fdpic returns 0, the contents of ELF_FDPIC_PLAT_INIT is (harmless) dead stores.

I don't follow. On other architectures that binfmt_elf-fdpic supoprts (so ARM, SH, M68K currently; historically some other removed architectures too) the contents of ELF_FDPIC_PLAT_INIT are always run if defined. Even in the case of loading a standard ELF binary. Those mappings are loaded into some registers and those appear in the running process on startup.

Quoted 7 lines

We don't have an implementation of elf_check_fdpic yet, which means that we cannot load binaries that actually use the load maps and the ELF_FDPIC_PLAT_INIT is dead code. Dead code which is unlikely to conform to the future ABI, since the RISC-V psABI Task Group has yet to choose which registers to use to pass the load maps. Since the code is dead and likely wrong, it should be removed so that correct code can be added at the correct time.

I understand your reluctance here.

Regards
Greg

Quoted 98 lines

-s
Quoted 96 lines
Quoted 2 lines
I'd ask if there's a reason it starts at a1 instead of a0, but it seems idiosyncratic on all arches that have full FDPIC support.
This comment in the crt1.S code of uClibc made me think that a0 already had a pre-defined use in the ABI:
/* The entry point's job is to call __uClibc_main. Per the ABI,
a0 contains the address of a function to be passed to atexit.
But I didn't dig any further than that.
Regards
Greg
Quoted 72 lines
-s
Quoted 70 lines
arch/riscv/include/asm/elf.h +0 -0
   /*
    * This yields a string that ld.so will use to load implementation
* specific libraries for optimization. This is more specific in
arch/riscv/include/asm/elf.h +2 -1
@@ -78,7 +86,6 @@ extern unsigned long elf_hwcap;
 
   #define COMPAT_ELF_PLATFORM	(NULL)
 
-#ifdef CONFIG_MMU
   #define ARCH_DLINFO						\
   do {								\
   	/*							\
@@ -115,6 +122,8 @@ do {								\
   	else							 \
   		NEW_AUX_ENT(AT_IGNORE, 0);			 \
   } while (0)
+
+#ifdef CONFIG_MMU
   #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
   struct linux_binprm;
   extern int arch_setup_additional_pages(struct linux_binprm *bprm,
arch/riscv/include/asm/mmu.h +4 -0
index 0099dc116168..355504b37f8e 100644
@@ -20,6 +20,10 @@ typedef struct {
   	/* A local icache flush is needed before user execution can resume. */
   	cpumask_t icache_stale_mask;
   #endif
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+	unsigned long exec_fdpic_loadmap;
+	unsigned long interp_fdpic_loadmap;
+#endif
   } mm_context_t;
 
   void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t
pa,
arch/riscv/include/uapi/asm/ptrace.h +5 -0
index e17c550986a6..30f6d6537adc 100644
@@ -10,6 +10,11 @@
 
   #include <linux/types.h>
 
+#define PTRACE_GETFDPIC		33
+
+#define PTRACE_GETFDPIC_EXEC	0
+#define PTRACE_GETFDPIC_INTERP	1
+
   /*
    * User-mode register state for core dumps, ptrace, sigcontext
    *
fs/Kconfig.binfmt +1 -1
index 93539aac0e5b..f5693164ca9a 100644
@@ -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 || SUPERH || 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
Signature · 1 line
2.25.1
Quoted 4 lines
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

Stefan O'Rear

2023-07-14 16:40 UTC #10 lore raw

Re: [PATCH v2 2/2] riscv: support the elf-fdpic binfmt loader

Quoted 74 lines · Greg Ungerer

Quoted 65 lines · Stefan O'Rear
Quoted 50 lines · Greg Ungerer
Quoted 36 lines · Stefan O'Rear
Quoted 35 lines · Greg Ungerer
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process.
One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie.
Signed-off-by Greg Ungerer <[email protected]>
---
v1->v2: rebase onto linux-6.5-rc1
increment PTRACE_GETFDPIC value to keep it unique
   arch/riscv/include/asm/elf.h         | 11 ++++++++++-
   arch/riscv/include/asm/mmu.h         |  4 ++++
   arch/riscv/include/uapi/asm/ptrace.h |  5 +++++
   fs/Kconfig.binfmt                    |  2 +-
   4 files changed, 20 insertions(+), 2 deletions(-)
arch/riscv/include/asm/elf.h +1 -0
index c24280774caf..c33fe923ef6d 100644
@@ -41,6 +41,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
   #define compat_elf_check_arch	compat_elf_check_arch
 
   #define CORE_DUMP_USE_REGSET
+#define ELF_FDPIC_CORE_EFLAGS	0
   #define ELF_EXEC_PAGESIZE	(PAGE_SIZE)
 
   /*
@@ -69,6 +70,13 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
   #define ELF_HWCAP	riscv_get_elf_hwcap()
   extern unsigned long elf_hwcap;
 
Quoted 12 lines
arch/riscv/include/asm/elf.h extern bool compat_elf_check_arch(Elf32_Ehdr *hdr); · line 79
Quoted 8 lines
arch/riscv/include/asm/elf.h +7 -0
+#define ELF_FDPIC_PLAT_INIT(_r, _exec_map_addr, _interp_map_addr,
 dynamic_addr) \
+	do { \
+		(_r)->a1 = _exec_map_addr; \
+		(_r)->a2 = _interp_map_addr; \
+		(_r)->a3 = dynamic_addr; \
+	} while (0)
+
This should probably be left empty for now; it will be defined by the ELF FDPIC ABI when that is done, and shouldn't be used by normal ELF binaries.
Quoted 2 lines
True, not used by the ELF binaries themselves. But used by an ELF interpreter to do the runtime relocations.
By "normal ELF binaries", I mean binaries (executables and shared libraries with nonzero e_entry, including statically linked binaries and the dynamic linker itself) that conform to the psABI as it currently exists in riscv-elf-psabi-doc.
These binaries don't use load maps because they aren't defined in riscv-elf-psabi-doc yet. At some point in the future, riscv-elf-psabi-doc may define a FDPIC EI_OSABI value and rules for its usage; "FDPIC ELF binaries" will not be "normal" and you will not be able to load them with binfmt_elf or binfmt_elf_compat.
Quoted 3 lines
"FDPIC elf binaries" which contain their own self-relocation code, including the dynamic linker and statically linked binaries, will use the map and dynamic addresses.
Well, yes, none of that is specific to RISC-V though. Those same rules apply to FDPIC binaries on any architecture that supports it. FDPIC binaries can only be loaded by binfmt_elf_fdpic.

Quoted 7 lines

The point I was trying to make is that with a normal ELF binary (with obvious limitations in the noMMU case - needs to be PIE, and not using shared libraries, etc) if those mappings are present a specially crafted ELF interpreter can use them to carry out the relocations and start that ELF binary. That ELF binary is not special and can be loaded and run by the the standard binfmt_elf ELF loader on an a fully MMU system (of course using the usual ELF interpreter on that system not the different noMMU one).

I agree with everything in these two paragraphs.

The point I'm trying to make is that the "specially crafted ELF interpreter" doesn't need to use the load maps - all of the information in exec_loadmap and dynamic can be obtained by scanning AT_PHDR and adding the an offset to all of them such that the address of PT_PHDR is the value of AT_PHDR; all of the information in interp_loadmap can be obtained using AT_BASE.

I believe that musl ldso is already designed to operate in this way and it already has fallback code for read instead of failing mmaps, if you add #define DL_NOMMU_SUPPORT 1 to arch/riscv64/reloc.h, although I haven't tested it. I do not understand the glibc or uclibc interpreters well enough to make statements about them.

Quoted 10 lines

Quoted 4 lines
elf_check_fdpic will return 1 for binaries that use the FDPIC EI_OSABI and use the load maps as part of either their own or their interpreter's startup code. For binaries where elf_check_fdpic returns 0, the contents of ELF_FDPIC_PLAT_INIT is (harmless) dead stores.
I don't follow. On other architectures that binfmt_elf-fdpic supoprts (so ARM, SH, M68K currently; historically some other removed architectures too) the contents of ELF_FDPIC_PLAT_INIT are always run if defined. Even in the case of loading a standard ELF binary. Those mappings are loaded into some registers and those appear in the running process on startup.

Dead in the sense that there is no way for a constdisp ELF executable, which must run correctly with binfmt_elf, to make use of them - if I have understood ELF_PLAT_INIT and start_thread correctly, RISC-V executables and interpreters currently start with garbage from the pre-execve state in all integer registers other than sp, so there is no way to distinguish "valid load maps" from "nonzero values from previous image".

-s

Quoted 112 lines

Quoted 7 lines
We don't have an implementation of elf_check_fdpic yet, which means that we cannot load binaries that actually use the load maps and the ELF_FDPIC_PLAT_INIT is dead code. Dead code which is unlikely to conform to the future ABI, since the RISC-V psABI Task Group has yet to choose which registers to use to pass the load maps. Since the code is dead and likely wrong, it should be removed so that correct code can be added at the correct time.
I understand your reluctance here.
Regards
Greg
Quoted 98 lines
-s
Quoted 96 lines
Quoted 2 lines
I'd ask if there's a reason it starts at a1 instead of a0, but it seems idiosyncratic on all arches that have full FDPIC support.
This comment in the crt1.S code of uClibc made me think that a0 already had a pre-defined use in the ABI:
/* The entry point's job is to call __uClibc_main. Per the ABI,
a0 contains the address of a function to be passed to atexit.
But I didn't dig any further than that.
Regards
Greg
Quoted 72 lines
-s
Quoted 70 lines
arch/riscv/include/asm/elf.h +0 -0
   /*
    * This yields a string that ld.so will use to load implementation
* specific libraries for optimization. This is more specific in
arch/riscv/include/asm/elf.h +2 -1
@@ -78,7 +86,6 @@ extern unsigned long elf_hwcap;
 
   #define COMPAT_ELF_PLATFORM	(NULL)
 
-#ifdef CONFIG_MMU
   #define ARCH_DLINFO						\
   do {								\
   	/*							\
@@ -115,6 +122,8 @@ do {								\
   	else							 \
   		NEW_AUX_ENT(AT_IGNORE, 0);			 \
   } while (0)
+
+#ifdef CONFIG_MMU
   #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
   struct linux_binprm;
   extern int arch_setup_additional_pages(struct linux_binprm *bprm,
arch/riscv/include/asm/mmu.h +4 -0
index 0099dc116168..355504b37f8e 100644
@@ -20,6 +20,10 @@ typedef struct {
   	/* A local icache flush is needed before user execution can resume. */
   	cpumask_t icache_stale_mask;
   #endif
+#ifdef CONFIG_BINFMT_ELF_FDPIC
+	unsigned long exec_fdpic_loadmap;
+	unsigned long interp_fdpic_loadmap;
+#endif
   } mm_context_t;
 
   void __init create_pgd_mapping(pgd_t *pgdp, uintptr_t va, phys_addr_t
pa,
arch/riscv/include/uapi/asm/ptrace.h +5 -0
index e17c550986a6..30f6d6537adc 100644
@@ -10,6 +10,11 @@
 
   #include <linux/types.h>
 
+#define PTRACE_GETFDPIC		33
+
+#define PTRACE_GETFDPIC_EXEC	0
+#define PTRACE_GETFDPIC_INTERP	1
+
   /*
    * User-mode register state for core dumps, ptrace, sigcontext
    *
fs/Kconfig.binfmt +1 -1
index 93539aac0e5b..f5693164ca9a 100644
@@ -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 || SUPERH || 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
Signature · 1 line
2.25.1
Quoted 4 lines
Quoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

[email protected]

CI Applied

2023-08-30 13:20 UTC #11 lore raw

In reply to Greg Ungerer

This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt <[email protected]>:

Hello:

This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt <[email protected]>:

Quoted 10 lines · On Tue, 11 Jul 2023 23:07:52 +1000 you wrote:

The following changes add the ability to run ELF format binaries when running RISC-V in nommu mode. That support is actually part of the ELF-FDPIC loader, so these changes are all about making that work on RISC-V.
The first issue to deal with is making the ELF-FDPIC loader capable of handling 64-bit ELF files. As coded right now it only supports 32-bit ELF files.
[...]

Here is the summary with links:
- [v2,1/2] binfmt_elf_fdpic: support 64-bit systems

    https://git.kernel.org/riscv/c/b922bf04d2c1
  - [v2,2/2] riscv: support the elf-fdpic binfmt loader
    https://git.kernel.org/riscv/c/9549fb354ef1

You are awesome, thank you!

Signature · 2 lines

Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html