[PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[PATCH v5 02/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
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
-- 
2.43.0

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Eric W. Biederman]

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

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Hajime Tazaki]

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

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Eric W. Biederman]

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

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Hajime Tazaki]

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

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Eric W. Biederman]

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

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Hajime Tazaki]

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

Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic

[Kees Cook]

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>

-- 
Kees Cook