[PATCH RESEND v11 01/13] x86/um: nommu: elf loader for fdpic

[PATCH RESEND v11 01/13] x86/um: nommu: elf loader for fdpic

[Hajime Tazaki]

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
Acked-by: Kees Cook <kees@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 4d0e4239f3cc..e9661846b4a3 100644
--- a/arch/um/include/asm/mmu.h
+++ b/arch/um/include/asm/mmu.h
@@ -17,6 +17,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 86d74f9d33cf..62e9916078ec 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
-- 
2.43.0

Re: [PATCH RESEND v11 10/13] um: nommu: a work around for MMU dependency to PCI driver

[Arnd Bergmann]

On Wed, Sep 24, 2025, at 01:51, Hajime Tazaki wrote:
> On Wed, 24 Sep 2025 02:13:47 +0900, Johannes Berg wrote:
>> On Tue, 2025-09-23 at 17:42 +0200, Geert Uytterhoeven wrote:
>> > > 
>> > > currently, drivers/pci/Kconfig (CONFIG_PCI) marks as depends on MMU,
>> > > so we cannot select it when CONFIG_MMU=n.
>> > 
>> > That is a fairly recent change, see commit 8fe743b5eba0abfb ("PCI:
>> > Add CONFIG_MMU dependency") in v6.16-rc1.  As this is not a "hard"
>> > dependency, perhaps it should be reverted, iff you are willing to take
>> > care of the casual breakage?
>> 
>> Why though? UML with PCI can't really be a functional thing, only a
>> testing thing, and testing PCI on !MMU when that is actually impossible
>> in non-simulation is pointless?
>
> currently nommu UML doesn't come with using PCI except building under
> kunit (ARCH=um), but I have in my mind to use it under !MMU
> environment, so would be an option in the future.
>
> and this series doesn't include PCI w/ !MMU.
>
> so, I would propose the modification to revert the MMU dependency when
> time has come.

The reason why it's currently disabled is that it was causing extra
work to fix build failures in random PCI drivers that individually
have a CONFIG_MMU dependency. Since we know that none of the NOMMU
boards we support uses PCI, this was an easy way to avoid work.

While there are still developers that care about NOMMU Linux
and test it on the platforms they use, the NOMMU build failures
usually end up in code that are irrelevant for their use cases,
so neither the platform owners nor the driver authors care deeply
about fixing that combination.

If you want to be able to use PCI drivers on UML-NOMMU,
you can probably use

config PCI
       depends on MMU || UML

so it will be ignored by the build bots on other architectures.
You'll still have to decide whether to fix driver code when
regressions in PCI drivers happen, add 'depends on !UML'
to individual drivers, or just live with randconfig failures.

      Arnd

Re: [PATCH RESEND v11 10/13] um: nommu: a work around for MMU dependency to PCI driver

[Hajime Tazaki]

Hello Arnd,

On Wed, 24 Sep 2025 20:03:11 +0900,
Arnd Bergmann wrote:

> > currently nommu UML doesn't come with using PCI except building under
> > kunit (ARCH=um), but I have in my mind to use it under !MMU
> > environment, so would be an option in the future.
> >
> > and this series doesn't include PCI w/ !MMU.
> >
> > so, I would propose the modification to revert the MMU dependency when
> > time has come.
> 
> The reason why it's currently disabled is that it was causing extra
> work to fix build failures in random PCI drivers that individually
> have a CONFIG_MMU dependency. Since we know that none of the NOMMU
> boards we support uses PCI, this was an easy way to avoid work.
> 
> While there are still developers that care about NOMMU Linux
> and test it on the platforms they use, the NOMMU build failures
> usually end up in code that are irrelevant for their use cases,
> so neither the platform owners nor the driver authors care deeply
> about fixing that combination.
> 
> If you want to be able to use PCI drivers on UML-NOMMU,
> you can probably use
> 
> config PCI
>        depends on MMU || UML
> 
> so it will be ignored by the build bots on other architectures.
> You'll still have to decide whether to fix driver code when
> regressions in PCI drivers happen, add 'depends on !UML'
> to individual drivers, or just live with randconfig failures.

thanks for the detail information.
yes, when nommu UML wish to use PCI drivers in the future, I'll take
this approach to be able to use it.

-- Hajime