[RFC,v2,02/13] x86/um: nommu: elf loader for fdpic

Commit Message

Hajime Tazaki Nov. 11, 2024, 6:27 a.m. UTC

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 <[e-mail]>
Cc: Kees Cook <[e-mail]>
Cc: Alexander Viro <[e-mail]>
Cc: Christian Brauner <[e-mail]>
Cc: Jan Kara <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Signed-off-by: Hajime Tazaki <[e-mail]>
Signed-off-by: Ricardo Koller <[e-mail]>
---
 arch/um/include/asm/Kbuild           |  1 +
 arch/um/include/asm/mmu.h            |  5 +++++
 arch/um/include/asm/ptrace-generic.h |  6 ++++++
 arch/x86/um/asm/elf.h                |  8 ++++++--
 arch/x86/um/asm/module.h             | 24 ------------------------
 fs/Kconfig.binfmt                    |  2 +-
 6 files changed, 19 insertions(+), 27 deletions(-)
 delete mode 100644 arch/x86/um/asm/module.h

Comments

Geert Uytterhoeven Nov. 12, 2024, 12:48 p.m. UTC | #1

Hi Tazaki-san,

On Mon, Nov 11, 2024 at 7:28 AM Hajime Tazaki <[e-mail]> 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 <[e-mail]>
> Cc: Kees Cook <[e-mail]>
> Cc: Alexander Viro <[e-mail]>
> Cc: Christian Brauner <[e-mail]>
> Cc: Jan Kara <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Signed-off-by: Hajime Tazaki <[e-mail]>
> Signed-off-by: Ricardo Koller <[e-mail]>

Thanks for your patch!

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

s/UML/X86/?

>         select ELFCORE
>         help
>           ELF FDPIC binaries are based on ELF, but allow the individual load

Gr{oetje,eeting}s,

                        Geert

Hajime Tazaki Nov. 12, 2024, 10:07 p.m. UTC | #2

Hello Geert,

thank you for the message.

On Tue, 12 Nov 2024 21:48:28 +0900,
Geert Uytterhoeven wrote:
>
> On Mon, Nov 11, 2024 at 7:28 AM Hajime Tazaki <[e-mail]> 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 <[e-mail]>
> > Cc: Kees Cook <[e-mail]>
> > Cc: Alexander Viro <[e-mail]>
> > Cc: Christian Brauner <[e-mail]>
> > Cc: Jan Kara <[e-mail]>
> > Cc: [e-mail]
> > Cc: [e-mail]
> > Signed-off-by: Hajime Tazaki <[e-mail]>
> > Signed-off-by: Ricardo Koller <[e-mail]>
> 
> Thanks for your patch!
> 
> > --- 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)
> 
> s/UML/X86/?

I guess the fdpic loader can be used to X86, but this patchset only
adds UML to be able to select it.  I intended to add UML into nommu
family.

-- Hajime

Geert Uytterhoeven Nov. 13, 2024, 8:19 a.m. UTC | #3

Hi Tazaki-san,

On Tue, Nov 12, 2024 at 11:07 PM Hajime Tazaki <[e-mail]> wrote:
> On Tue, 12 Nov 2024 21:48:28 +0900,
> > On Mon, Nov 11, 2024 at 7:28 AM Hajime Tazaki <[e-mail]> 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 <[e-mail]>
> > > Cc: Kees Cook <[e-mail]>
> > > Cc: Alexander Viro <[e-mail]>
> > > Cc: Christian Brauner <[e-mail]>
> > > Cc: Jan Kara <[e-mail]>
> > > Cc: [e-mail]
> > > Cc: [e-mail]
> > > Signed-off-by: Hajime Tazaki <[e-mail]>
> > > Signed-off-by: Ricardo Koller <[e-mail]>
> >
> > Thanks for your patch!
> >
> > > --- 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)
> >
> > s/UML/X86/?
>
> I guess the fdpic loader can be used to X86, but this patchset only
> adds UML to be able to select it.  I intended to add UML into nommu
> family.

While currently x86-nommu is supported for UML only, this is really
x86-specific. I still hope UML will get support for other architectures
one day, at which point a dependency on UML here will become wrong...

Gr{oetje,eeting}s,

                        Geert

Johannes Berg Nov. 13, 2024, 8:36 a.m. UTC | #4

On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> 
> > > > -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
> > > 
> > > s/UML/X86/?
> > 
> > I guess the fdpic loader can be used to X86, but this patchset only
> > adds UML to be able to select it.  I intended to add UML into nommu
> > family.
> 
> While currently x86-nommu is supported for UML only, this is really
> x86-specific. I still hope UML will get support for other architectures
> one day, at which point a dependency on UML here will become wrong...
> 

X86 isn't set for UML, X64_32 and X64_64 are though.

Given that the no-MMU UM support even is 64-bit only, that probably
should then really be (UML && X86_64).

But it already has !MMU, so can't be selected otherwise, and it seems
that non-X86 UML 

johannes

Johannes Berg Nov. 13, 2024, 8:36 a.m. UTC | #5

(sorry, fat-fingered that)

On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
> On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> > 
> > > > > -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > > +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
> > > > 
> > > > s/UML/X86/?
> > > 
> > > I guess the fdpic loader can be used to X86, but this patchset only
> > > adds UML to be able to select it.  I intended to add UML into nommu
> > > family.
> > 
> > While currently x86-nommu is supported for UML only, this is really
> > x86-specific. I still hope UML will get support for other architectures
> > one day, at which point a dependency on UML here will become wrong...
> > 
> 
> X86 isn't set for UML, X64_32 and X64_64 are though.
> 
> Given that the no-MMU UM support even is 64-bit only, that probably
> should then really be (UML && X86_64).
> 
> But it already has !MMU, so can't be selected otherwise, and it seems
> that non-X86 UML 

... would require far more changes in all kinds of places, so not sure
I'd be too concerned about it here.

johannes

Geert Uytterhoeven Nov. 13, 2024, 10:27 a.m. UTC | #6

Hi Johannes,

On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <[e-mail]> wrote:
> On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
> > On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> > >
> > > > > > -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > > > +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
> > > > >
> > > > > s/UML/X86/?
> > > >
> > > > I guess the fdpic loader can be used to X86, but this patchset only
> > > > adds UML to be able to select it.  I intended to add UML into nommu
> > > > family.
> > >
> > > While currently x86-nommu is supported for UML only, this is really
> > > x86-specific. I still hope UML will get support for other architectures
> > > one day, at which point a dependency on UML here will become wrong...
> > >
> >
> > X86 isn't set for UML, X64_32 and X64_64 are though.
> >
> > Given that the no-MMU UM support even is 64-bit only, that probably
> > should then really be (UML && X86_64).
> >
> > But it already has !MMU, so can't be selected otherwise, and it seems
> > that non-X86 UML
>
> ... would require far more changes in all kinds of places, so not sure
> I'd be too concerned about it here.

OK, up to you...

Gr{oetje,eeting}s,

                        Geert

Hajime Tazaki Nov. 13, 2024, 1:17 p.m. UTC | #7

Hello,

thanks for the inputs Geert, Johannes,

On Wed, 13 Nov 2024 19:27:08 +0900,
Geert Uytterhoeven wrote:
> 
> Hi Johannes,
> 
> On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <[e-mail]> wrote:
> > On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
> > > On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> > > >
> > > > > > > -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > > > > +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
> > > > > >
> > > > > > s/UML/X86/?
> > > > >
> > > > > I guess the fdpic loader can be used to X86, but this patchset only
> > > > > adds UML to be able to select it.  I intended to add UML into nommu
> > > > > family.
> > > >
> > > > While currently x86-nommu is supported for UML only, this is really
> > > > x86-specific. I still hope UML will get support for other architectures
> > > > one day, at which point a dependency on UML here will become wrong...
> > > >
> > >
> > > X86 isn't set for UML, X64_32 and X64_64 are though.
> > >
> > > Given that the no-MMU UM support even is 64-bit only, that probably
> > > should then really be (UML && X86_64).
> > >
> > > But it already has !MMU, so can't be selected otherwise, and it seems
> > > that non-X86 UML
> >
> > ... would require far more changes in all kinds of places, so not sure
> > I'd be too concerned about it here.
> 
> OK, up to you...

Indeed, this particular patch [02/13] intends to support the fdpic
loader under the condition 1) x86_64 ELF binaries (w/ PIE), 2) on UML,
3) and with) !MMU configured.  Given that situation, the strict check
should be like:

   depends on ARM || ((M68K || RISCV || SUPERH || (UML && X86_64) || XTENSA) && !MMU)

(as Johannes mentioned).

on the other hand, the fdpic loader works (afaik) on MMU environment so,

   depends on ARM || (UML && X86_64) || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)

should also works, but this might be too broad for this patchset (and
not sure if this makes a new use case).

anyway, thank you for the comment.
# I really wanted to have comments from nommu folks.

-- Hajime

Geert Uytterhoeven Nov. 13, 2024, 1:55 p.m. UTC | #8

Hi Tazaki-san,

On Wed, Nov 13, 2024 at 2:17 PM Hajime Tazaki <[e-mail]> wrote:
> On Wed, 13 Nov 2024 19:27:08 +0900,
> Geert Uytterhoeven wrote:
> > On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <[e-mail]> wrote:
> > > On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
> > > > On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> > > > >
> > > > > > > > -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > > > > > +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
> > > > > > >
> > > > > > > s/UML/X86/?
> > > > > >
> > > > > > I guess the fdpic loader can be used to X86, but this patchset only
> > > > > > adds UML to be able to select it.  I intended to add UML into nommu
> > > > > > family.
> > > > >
> > > > > While currently x86-nommu is supported for UML only, this is really
> > > > > x86-specific. I still hope UML will get support for other architectures
> > > > > one day, at which point a dependency on UML here will become wrong...
> > > > >
> > > >
> > > > X86 isn't set for UML, X64_32 and X64_64 are though.
> > > >
> > > > Given that the no-MMU UM support even is 64-bit only, that probably
> > > > should then really be (UML && X86_64).
> > > >
> > > > But it already has !MMU, so can't be selected otherwise, and it seems
> > > > that non-X86 UML
> > >
> > > ... would require far more changes in all kinds of places, so not sure
> > > I'd be too concerned about it here.
> >
> > OK, up to you...
>
> Indeed, this particular patch [02/13] intends to support the fdpic
> loader under the condition 1) x86_64 ELF binaries (w/ PIE), 2) on UML,
> 3) and with) !MMU configured.  Given that situation, the strict check
> should be like:
>
>    depends on ARM || ((M68K || RISCV || SUPERH || (UML && X86_64) || XTENSA) && !MMU)
>
> (as Johannes mentioned).
>
> on the other hand, the fdpic loader works (afaik) on MMU environment so,
>
>    depends on ARM || (UML && X86_64) || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
>
> should also works, but this might be too broad for this patchset (and
> not sure if this makes a new use case).

AFAIK that depends on the architecture's MMU context structure, cfr.
the comment in commit 782f4c5c44e7d99d ("m68knommu: allow elf_fdpic
loader to be selected"), which restricts it to nommu on m68k.  If it
does work on X86_64, you can drop the dependency on UML, and we're
(almost) back to my initial comment ;-)

> anyway, thank you for the comment.
> # I really wanted to have comments from nommu folks.

I've added some in CC...

Gr{oetje,eeting}s,

                        Geert

Hajime Tazaki Nov. 13, 2024, 11:32 p.m. UTC | #9

On Wed, 13 Nov 2024 22:55:02 +0900,
Geert Uytterhoeven wrote:
> On Wed, Nov 13, 2024 at 2:17 PM Hajime Tazaki <[e-mail]> wrote:
> > On Wed, 13 Nov 2024 19:27:08 +0900,
> > Geert Uytterhoeven wrote:
> > > On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <[e-mail]> wrote:
> > > > On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
> > > > > On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
> > > > > >
> > > > > > > > > -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> > > > > > > > > +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
> > > > > > > >
> > > > > > > > s/UML/X86/?
> > > > > > >
> > > > > > > I guess the fdpic loader can be used to X86, but this patchset only
> > > > > > > adds UML to be able to select it.  I intended to add UML into nommu
> > > > > > > family.
> > > > > >
> > > > > > While currently x86-nommu is supported for UML only, this is really
> > > > > > x86-specific. I still hope UML will get support for other architectures
> > > > > > one day, at which point a dependency on UML here will become wrong...
> > > > > >
> > > > >
> > > > > X86 isn't set for UML, X64_32 and X64_64 are though.
> > > > >
> > > > > Given that the no-MMU UM support even is 64-bit only, that probably
> > > > > should then really be (UML && X86_64).
> > > > >
> > > > > But it already has !MMU, so can't be selected otherwise, and it seems
> > > > > that non-X86 UML
> > > >
> > > > ... would require far more changes in all kinds of places, so not sure
> > > > I'd be too concerned about it here.
> > >
> > > OK, up to you...
> >
> > Indeed, this particular patch [02/13] intends to support the fdpic
> > loader under the condition 1) x86_64 ELF binaries (w/ PIE), 2) on UML,
> > 3) and with) !MMU configured.  Given that situation, the strict check
> > should be like:
> >
> >    depends on ARM || ((M68K || RISCV || SUPERH || (UML && X86_64) || XTENSA) && !MMU)
> >
> > (as Johannes mentioned).
> >
> > on the other hand, the fdpic loader works (afaik) on MMU environment so,
> >
> >    depends on ARM || (UML && X86_64) || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
> >
> > should also works, but this might be too broad for this patchset (and
> > not sure if this makes a new use case).
> 
> AFAIK that depends on the architecture's MMU context structure, cfr.
> the comment in commit 782f4c5c44e7d99d ("m68knommu: allow elf_fdpic
> loader to be selected"), which restricts it to nommu on m68k.  If it
> does work on X86_64, you can drop the dependency on UML, and we're
> (almost) back to my initial comment ;-)

I checked and it doesn't work as-is with (UML_X86_64 && MMU).
restricting nommu with UML might be a good to for this patch.

even if it works, I would like to focus on UML && !MMU for this patch
series since I wish to make the (initial) patchset as small as
possible.  If we would like to make it broadly available on x86, that
would be a different patch.

> > anyway, thank you for the comment.
> > # I really wanted to have comments from nommu folks.
> 
> I've added some in CC...

Thanks,

-- Hajime

Greg Ungerer Nov. 14, 2024, 1:40 a.m. UTC | #10

Hi Hajime,

On 14/11/24 09:32, Hajime Tazaki wrote:
> On Wed, 13 Nov 2024 22:55:02 +0900,
> Geert Uytterhoeven wrote:
>> On Wed, Nov 13, 2024 at 2:17 PM Hajime Tazaki <[e-mail]> wrote:
>>> On Wed, 13 Nov 2024 19:27:08 +0900,
>>> Geert Uytterhoeven wrote:
>>>> On Wed, Nov 13, 2024 at 9:37 AM Johannes Berg <[e-mail]> wrote:
>>>>> On Wed, 2024-11-13 at 09:36 +0100, Johannes Berg wrote:
>>>>>> On Wed, 2024-11-13 at 09:19 +0100, Geert Uytterhoeven wrote:
>>>>>>>
>>>>>>>>>> -       depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
>>>>>>>>>> +       depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && !MMU)
>>>>>>>>>
>>>>>>>>> s/UML/X86/?
>>>>>>>>
>>>>>>>> I guess the fdpic loader can be used to X86, but this patchset only
>>>>>>>> adds UML to be able to select it.  I intended to add UML into nommu
>>>>>>>> family.
>>>>>>>
>>>>>>> While currently x86-nommu is supported for UML only, this is really
>>>>>>> x86-specific. I still hope UML will get support for other architectures
>>>>>>> one day, at which point a dependency on UML here will become wrong...
>>>>>>>
>>>>>>
>>>>>> X86 isn't set for UML, X64_32 and X64_64 are though.
>>>>>>
>>>>>> Given that the no-MMU UM support even is 64-bit only, that probably
>>>>>> should then really be (UML && X86_64).
>>>>>>
>>>>>> But it already has !MMU, so can't be selected otherwise, and it seems
>>>>>> that non-X86 UML
>>>>>
>>>>> ... would require far more changes in all kinds of places, so not sure
>>>>> I'd be too concerned about it here.
>>>>
>>>> OK, up to you...
>>>
>>> Indeed, this particular patch [02/13] intends to support the fdpic
>>> loader under the condition 1) x86_64 ELF binaries (w/ PIE), 2) on UML,
>>> 3) and with) !MMU configured.  Given that situation, the strict check
>>> should be like:
>>>
>>>     depends on ARM || ((M68K || RISCV || SUPERH || (UML && X86_64) || XTENSA) && !MMU)
>>>
>>> (as Johannes mentioned).
>>>
>>> on the other hand, the fdpic loader works (afaik) on MMU environment so,
>>>
>>>     depends on ARM || (UML && X86_64) || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
>>>
>>> should also works, but this might be too broad for this patchset (and
>>> not sure if this makes a new use case).
>>
>> AFAIK that depends on the architecture's MMU context structure, cfr.
>> the comment in commit 782f4c5c44e7d99d ("m68knommu: allow elf_fdpic
>> loader to be selected"), which restricts it to nommu on m68k.  If it
>> does work on X86_64, you can drop the dependency on UML, and we're
>> (almost) back to my initial comment ;-)
> 
> I checked and it doesn't work as-is with (UML_X86_64 && MMU).
> restricting nommu with UML might be a good to for this patch.
> 
> even if it works, I would like to focus on UML && !MMU for this patch
> series since I wish to make the (initial) patchset as small as
> possible.  If we would like to make it broadly available on x86, that
> would be a different patch.

Makes sense.

I was only interested in the ability to run ELF based static/PIE binaries
when I did 782f4c5c44e7d99d ("m68knommu: allow elf_fdpic loader to be selected").
I did the same thing for RISC-V in commit 9549fb354ef1 ("riscv: support the
elf-fdpic binfmt loader"), limiting it to !MMU configurations only.

There is no need for binfmt_fdpic in MMU configurations if all you want to
do is run ELF PIE binaries. The normal binfmt_elf loader can load and run
those already.

Regards
Greg



>>> anyway, thank you for the comment.
>>> # I really wanted to have comments from nommu folks.
>>
>> I've added some in CC...
> 
> Thanks,
> 
> -- Hajime

Patch

diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
index 18f902da8e99..cf8260fdcfe5 100644
--- a/arch/um/include/asm/Kbuild
+++ b/arch/um/include/asm/Kbuild
@@ -14,6 +14,7 @@  generic-y += irq_work.h
 generic-y += kdebug.h
 generic-y += mcs_spinlock.h
 generic-y += mmiowb.h
+generic-y += module.h
 generic-y += module.lds.h
 generic-y += param.h
 generic-y += parport.h
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/arch/x86/um/asm/module.h b/arch/x86/um/asm/module.h
deleted file mode 100644
index a3b061d66082..000000000000
--- a/arch/x86/um/asm/module.h
+++ /dev/null
@@ -1,24 +0,0 @@ 
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __UM_MODULE_H
-#define __UM_MODULE_H
-
-/* UML is simple */
-struct mod_arch_specific
-{
-};
-
-#ifdef CONFIG_X86_32
-
-#define Elf_Shdr Elf32_Shdr
-#define Elf_Sym Elf32_Sym
-#define Elf_Ehdr Elf32_Ehdr
-
-#else
-
-#define Elf_Shdr Elf64_Shdr
-#define Elf_Sym Elf64_Sym
-#define Elf_Ehdr Elf64_Ehdr
-
-#endif
-
-#endif
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