[PATCH] alpha: Fix personality flag propagation across an exec

[PATCH] alpha: Fix personality flag propagation across an exec

[John Paul Adrian Glaubitz]

It was observed that on alpha, the misc/setarch test of
the util-linux testsuite failed with the following error:

   misc: setarch                        ...
          : options                     ... OK
          : uname26                     ... OK
          : uname26-version             ... FAILED (misc/setarch-uname26-version)
          : show                        ... OK
     ... FAILED (1 from 4 sub-tests)

Running the setarch binary manually confirmed that setting
the kernel version with the help --uname-2.6 flag does not
work and the version remains unchanged.

It turned out that on alpha, the personality flags are not
propagated but overridden during an exec. The same issue was
previously fixed on arm in commit 5e143436d044 ("ARM: 6878/1:
fix personality flag propagation across an exec") and on powerpc
in commit a91a03ee31a5 ("powerpc: Keep 3 high personality bytes
across exec"). This patch fixes the issue on alpha.

With the patch applied, the misc/setarch test succeeds on
alpha as expected:

   misc: setarch                        ...
          : options                     ... OK
          : uname26                     ... OK
          : uname26-version             ... OK
          : show                        ... OK
     ... OK (all 4 sub-tests PASSED)

However, as a side-effect, a warning is printed on the kernel
message buffer which might indicate another unreleated bug:

[   39.964823] pid=509, couldn't seal address 0, ret=-12.

Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
---
 arch/alpha/include/asm/elf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
index 4d7c46f50382..81f8473bb7c0 100644
--- a/arch/alpha/include/asm/elf.h
+++ b/arch/alpha/include/asm/elf.h
@@ -138,8 +138,8 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
 })
 
 #define SET_PERSONALITY(EX)					\
-	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
-	   ? PER_LINUX_32BIT : PER_LINUX)
+	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
+	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
 
 extern int alpha_l1i_cacheshape;
 extern int alpha_l1d_cacheshape;
-- 
2.39.5

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Kees Cook]

On Fri, Jan 03, 2025 at 03:01:46PM +0100, John Paul Adrian Glaubitz wrote:
> It was observed that on alpha, the misc/setarch test of
> the util-linux testsuite failed with the following error:
> 
>    misc: setarch                        ...
>           : options                     ... OK
>           : uname26                     ... OK
>           : uname26-version             ... FAILED (misc/setarch-uname26-version)
>           : show                        ... OK
>      ... FAILED (1 from 4 sub-tests)
> 
> Running the setarch binary manually confirmed that setting
> the kernel version with the help --uname-2.6 flag does not
> work and the version remains unchanged.
> 
> It turned out that on alpha, the personality flags are not
> propagated but overridden during an exec. The same issue was
> previously fixed on arm in commit 5e143436d044 ("ARM: 6878/1:
> fix personality flag propagation across an exec") and on powerpc
> in commit a91a03ee31a5 ("powerpc: Keep 3 high personality bytes
> across exec"). This patch fixes the issue on alpha.

Good catch!

> 
> With the patch applied, the misc/setarch test succeeds on
> alpha as expected:
> 
>    misc: setarch                        ...
>           : options                     ... OK
>           : uname26                     ... OK
>           : uname26-version             ... OK
>           : show                        ... OK
>      ... OK (all 4 sub-tests PASSED)
> 
> However, as a side-effect, a warning is printed on the kernel
> message buffer which might indicate another unreleated bug:
> 
> [   39.964823] pid=509, couldn't seal address 0, ret=-12.

This is from mseal vs MMAP_PAGE_ZERO in fs/binfmt_elf.c

                error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
                                MAP_FIXED | MAP_PRIVATE, 0);

                retval = do_mseal(0, PAGE_SIZE, 0);
                if (retval)
                        pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
                                            task_pid_nr(current), retval);

-12 is ENOMEM, which implies, I think, that check_mm_seal() failed. I
note that "error" isn't being checked, so if the vm_mmap() failed, I
think the do_mseal() would fail with ENOMEM?

> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Reviewed-by: Kees Cook <kees@kernel.org>

-Kees

> ---
>  arch/alpha/include/asm/elf.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..81f8473bb7c0 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -138,8 +138,8 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
>  })
>  
>  #define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
> +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
>  
>  extern int alpha_l1i_cacheshape;
>  extern int alpha_l1d_cacheshape;
> -- 
> 2.39.5
> 

-- 
Kees Cook

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Jeff Xu]

On Wed, Jan 8, 2025 at 2:49 PM Kees Cook <kees@kernel.org> wrote:
>
> On Fri, Jan 03, 2025 at 03:01:46PM +0100, John Paul Adrian Glaubitz wrote:
> > It was observed that on alpha, the misc/setarch test of
> > the util-linux testsuite failed with the following error:
> >
> >    misc: setarch                        ...
> >           : options                     ... OK
> >           : uname26                     ... OK
> >           : uname26-version             ... FAILED (misc/setarch-uname26-version)
> >           : show                        ... OK
> >      ... FAILED (1 from 4 sub-tests)
> >
> > Running the setarch binary manually confirmed that setting
> > the kernel version with the help --uname-2.6 flag does not
> > work and the version remains unchanged.
> >
> > It turned out that on alpha, the personality flags are not
> > propagated but overridden during an exec. The same issue was
> > previously fixed on arm in commit 5e143436d044 ("ARM: 6878/1:
> > fix personality flag propagation across an exec") and on powerpc
> > in commit a91a03ee31a5 ("powerpc: Keep 3 high personality bytes
> > across exec"). This patch fixes the issue on alpha.
>
> Good catch!
>
> >
> > With the patch applied, the misc/setarch test succeeds on
> > alpha as expected:
> >
> >    misc: setarch                        ...
> >           : options                     ... OK
> >           : uname26                     ... OK
> >           : uname26-version             ... OK
> >           : show                        ... OK
> >      ... OK (all 4 sub-tests PASSED)
> >
> > However, as a side-effect, a warning is printed on the kernel
> > message buffer which might indicate another unreleated bug:
> >
> > [   39.964823] pid=509, couldn't seal address 0, ret=-12.
>
> This is from mseal vs MMAP_PAGE_ZERO in fs/binfmt_elf.c
>
>                 error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC,
>                                 MAP_FIXED | MAP_PRIVATE, 0);
>
>                 retval = do_mseal(0, PAGE_SIZE, 0);
>                 if (retval)
>                         pr_warn_ratelimited("pid=%d, couldn't seal address 0, ret=%d.\n",
>                                             task_pid_nr(current), retval);
>
> -12 is ENOMEM, which implies, I think, that check_mm_seal() failed. I
> note that "error" isn't being checked, so if the vm_mmap() failed, I
> think the do_mseal() would fail with ENOMEM?
>
Yes. do_mseal would fail with NOMEM if the address was not found.

It is likely that alpha doesn't allow creating a page on zero address
? i.e.  MMAP_PAGE_ZERO personality never worked on alpha.

-Jeff

> > Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>
> Reviewed-by: Kees Cook <kees@kernel.org>
>
> -Kees
>
> > ---
> >  arch/alpha/include/asm/elf.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> > index 4d7c46f50382..81f8473bb7c0 100644
> > --- a/arch/alpha/include/asm/elf.h
> > +++ b/arch/alpha/include/asm/elf.h
> > @@ -138,8 +138,8 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
> >  })
> >
> >  #define SET_PERSONALITY(EX)                                  \
> > -     set_personality(((EX).e_flags & EF_ALPHA_32BIT)         \
> > -        ? PER_LINUX_32BIT : PER_LINUX)
> > +     set_personality((((EX).e_flags & EF_ALPHA_32BIT)        \
> > +        ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
> >
> >  extern int alpha_l1i_cacheshape;
> >  extern int alpha_l1d_cacheshape;
> > --
> > 2.39.5
> >
>
> --
> Kees Cook
>

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Arnd Bergmann]

On Fri, Jan 3, 2025, at 15:01, John Paul Adrian Glaubitz wrote:

> 
>  #define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
> +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))

This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
PER_MASK, executing a regular binary from a taso binary no longer
reverts back to the entire 64-bit address space.

It seems that the behavior on most other architectures changed in 2012
commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
exec()").

At the time, the same bug existed on mips, parisc and tile, but those
got fixed quickly.

There are two related bits I don't quite understand:

- Do we still care about EF_ALPHA_32BIT? I see that it gets set by
 "alpha-linux-ld.bfd --taso", but could not find any documentation
 on what that flag is actually good for. On all other architectures,
 the address space limit gets enforced through a per-thread setting
 like TIF_32BIT, not through the personality that gets inherited
 by the child processes.

- all architectures other than x86 mask out the lower byte. Why
  not that one?

       Arnd

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Arnd Bergmann]

On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
> On Fri, Jan 3, 2025, at 15:01, John Paul Adrian Glaubitz wrote:
>
>> 
>>  #define SET_PERSONALITY(EX)					\
>> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
>> -	   ? PER_LINUX_32BIT : PER_LINUX)
>> +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
>> +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
>
> This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
> PER_MASK, executing a regular binary from a taso binary no longer
> reverts back to the entire 64-bit address space.
>
> It seems that the behavior on most other architectures changed in 2012
> commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
> exec()").
>
> At the time, the same bug existed on mips, parisc and tile, but those
> got fixed quickly.

Correction: from what I can tell, mips still has the bug (and now
also loongarch), it's just in SET_PERSONALITY2() now instead of
SET_PERSONALITY():

        current->personality &= ~READ_IMPLIES_EXEC;
        ...
        p = personality(current->personality);                          \
        if (p != PER_LINUX32 && p != PER_LINUX)                         \
                set_personality(PER_LINUX);                             \

personality() only returns the lower 8 bits (execution domain),
so if any of them are set (BSD/HPUX/IRIX32/IRIX64/...), both
the upper and the lower bits are cleared, otherwise neither
of them are.

The behavior on the other architectures is that we clear the
lower bits but keep the upper ones.

      Arnd

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[John Paul Adrian Glaubitz]

Hi Arnd,

thanks a lot for your feedback!

On Thu, 2025-01-09 at 09:43 +0100, Arnd Bergmann wrote:
> On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
> > On Fri, Jan 3, 2025, at 15:01, John Paul Adrian Glaubitz wrote:
> > 
> > > 
> > >  #define SET_PERSONALITY(EX)					\
> > > -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> > > -	   ? PER_LINUX_32BIT : PER_LINUX)
> > > +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
> > > +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
> > 
> > This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
> > PER_MASK, executing a regular binary from a taso binary no longer
> > reverts back to the entire 64-bit address space.
> > 
> > It seems that the behavior on most other architectures changed in 2012
> > commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
> > exec()").
> > 
> > At the time, the same bug existed on mips, parisc and tile, but those
> > got fixed quickly.
> 
> Correction: from what I can tell, mips still has the bug (and now
> also loongarch), it's just in SET_PERSONALITY2() now instead of
> SET_PERSONALITY():
> 
>         current->personality &= ~READ_IMPLIES_EXEC;
>         ...
>         p = personality(current->personality);                          \
>         if (p != PER_LINUX32 && p != PER_LINUX)                         \
>                 set_personality(PER_LINUX);                             \
> 
> personality() only returns the lower 8 bits (execution domain),
> so if any of them are set (BSD/HPUX/IRIX32/IRIX64/...), both
> the upper and the lower bits are cleared, otherwise neither
> of them are.
> 
> The behavior on the other architectures is that we clear the
> lower bits but keep the upper ones.

So, if I understand this correctly, we should just use PER_MASK on alpha
for 64-bit executables and allow the bits to be cleared for 32-bit binaries?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Arnd Bergmann]

On Thu, Jan 9, 2025, at 09:46, John Paul Adrian Glaubitz wrote:
> On Thu, 2025-01-09 at 09:43 +0100, Arnd Bergmann wrote:
>> On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
>> > On Fri, Jan 3, 2025, at 15:01, John Paul Adrian Glaubitz wrote:
>> > 
>> > > 
>> > >  #define SET_PERSONALITY(EX)					\
>> > > -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
>> > > -	   ? PER_LINUX_32BIT : PER_LINUX)
>> > > +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
>> > > +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
>> > 
>> > This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
>> > PER_MASK, executing a regular binary from a taso binary no longer
>> > reverts back to the entire 64-bit address space.
>> > 
>> > It seems that the behavior on most other architectures changed in 2012
>> > commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
>> > exec()").
>> > 
>
> So, if I understand this correctly, we should just use PER_MASK on alpha
> for 64-bit executables and allow the bits to be cleared for 32-bit binaries?

I think ideally the EF_ALPHA_32BIT handling should use TIF_32BIT
as we do on other architectures, at that point the custom SET_PERSONALITY()
can be removed in favor of the asm-generic version.

Alternatively this could do something like the arm32 version (note
that on arm, PER_LINUX_32BIT/ADDR_LIMIT_32BIT means "allow using
the entire 32-bit address space rather than limiting to 26 bits for
compatibility", while on alpha it means "use only 31 instead of
42 bits for addressing", but the logic can be the same):

        unsigned int personality = current->personality & ~PER_MASK;
        /*
         * APCS-26 is only valid for OABI executables
         */
        if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN &&
            (eflags & EF_ARM_APCS_26))
                personality &= ~ADDR_LIMIT_32BIT;
        else
                personality |= ADDR_LIMIT_32BIT;
        set_personality(personality);

In any case, I think we should fix alpha, mips and loongarch at
the same time, to make sure it doesn't take another decade to
fix the rest.

    Arnd

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[John Paul Adrian Glaubitz]

Hi Arnd,

On Thu, 2025-01-09 at 09:56 +0100, Arnd Bergmann wrote:
> On Thu, Jan 9, 2025, at 09:46, John Paul Adrian Glaubitz wrote:
> > On Thu, 2025-01-09 at 09:43 +0100, Arnd Bergmann wrote:
> > > On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
> > > > On Fri, Jan 3, 2025, at 15:01, John Paul Adrian Glaubitz wrote:
> > > > 
> > > > > 
> > > > >  #define SET_PERSONALITY(EX)					\
> > > > > -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> > > > > -	   ? PER_LINUX_32BIT : PER_LINUX)
> > > > > +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
> > > > > +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))
> > > > 
> > > > This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
> > > > PER_MASK, executing a regular binary from a taso binary no longer
> > > > reverts back to the entire 64-bit address space.
> > > > 
> > > > It seems that the behavior on most other architectures changed in 2012
> > > > commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
> > > > exec()").
> > > > 
> > 
> > So, if I understand this correctly, we should just use PER_MASK on alpha
> > for 64-bit executables and allow the bits to be cleared for 32-bit binaries?
> 
> I think ideally the EF_ALPHA_32BIT handling should use TIF_32BIT
> as we do on other architectures, at that point the custom SET_PERSONALITY()
> can be removed in favor of the asm-generic version.

I have thought about that as well but I wasn't sure whether the extra
mangling on alpha was necessary.

> Alternatively this could do something like the arm32 version (note
> that on arm, PER_LINUX_32BIT/ADDR_LIMIT_32BIT means "allow using
> the entire 32-bit address space rather than limiting to 26 bits for
> compatibility", while on alpha it means "use only 31 instead of
> 42 bits for addressing", but the logic can be the same):
> 
>         unsigned int personality = current->personality & ~PER_MASK;
>         /*
>          * APCS-26 is only valid for OABI executables
>          */
>         if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN &&
>             (eflags & EF_ARM_APCS_26))
>                 personality &= ~ADDR_LIMIT_32BIT;
>         else
>                 personality |= ADDR_LIMIT_32BIT;
>         set_personality(personality);

So, this would be the 100% correct for alpha then which would not loose
any functionality even for 32-bit binaries?

> In any case, I think we should fix alpha, mips and loongarch at
> the same time, to make sure it doesn't take another decade to
> fix the rest.

If you're willing to fix all three at once, I would be happy to help
with the testing on all three architectures as I have machines for all
of these.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Eric W. Biederman]

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:

> Hi Arnd,
>
> On Thu, 2025-01-09 at 09:56 +0100, Arnd Bergmann wrote:
>> On Thu, Jan 9, 2025, at 09:46, John Paul Adrian Glaubitz wrote:
>> > On Thu, 2025-01-09 at 09:43 +0100, Arnd Bergmann wrote:
>> > > On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
>> > > > On Fri, Jan 3, 2025, at 15:01, John Paul Adrian Glaubitz wrote:
>> > > > 
>> > > > > 
>> > > > >  #define SET_PERSONALITY(EX)					\
>> > > > > -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
>> > > > > -	   ? PER_LINUX_32BIT : PER_LINUX)
>> > > > > +	set_personality((((EX).e_flags & EF_ALPHA_32BIT)	\
>> > > > > +	   ? PER_LINUX_32BIT : PER_LINUX) | (current->personality & (~PER_MASK)))

*Grumble*

It would be good to move those EF_${ARCH} flags from
arch/${ARCH}/include/asm/elf.h to arch/${ARCH}/include/uapi/asm/elf.h

Simply because those flags are architecture specific ABI.

>> > > > This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
>> > > > PER_MASK, executing a regular binary from a taso binary no longer
>> > > > reverts back to the entire 64-bit address space.
>> > > > 
>> > > > It seems that the behavior on most other architectures changed in 2012
>> > > > commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
>> > > > exec()").
>> > > > 
>> > 
>> > So, if I understand this correctly, we should just use PER_MASK on alpha
>> > for 64-bit executables and allow the bits to be cleared for 32-bit binaries?
>> 
>> I think ideally the EF_ALPHA_32BIT handling should use TIF_32BIT
>> as we do on other architectures, at that point the custom SET_PERSONALITY()
>> can be removed in favor of the asm-generic version.
>
> I have thought about that as well but I wasn't sure whether the extra
> mangling on alpha was necessary.
>
>> Alternatively this could do something like the arm32 version (note
>> that on arm, PER_LINUX_32BIT/ADDR_LIMIT_32BIT means "allow using
>> the entire 32-bit address space rather than limiting to 26 bits for
>> compatibility", while on alpha it means "use only 31 instead of
>> 42 bits for addressing", but the logic can be the same):
>> 
>>         unsigned int personality = current->personality & ~PER_MASK;
>>         /*
>>          * APCS-26 is only valid for OABI executables
>>          */
>>         if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN &&
>>             (eflags & EF_ARM_APCS_26))
>>                 personality &= ~ADDR_LIMIT_32BIT;
>>         else
>>                 personality |= ADDR_LIMIT_32BIT;
>>         set_personality(personality);
>
> So, this would be the 100% correct for alpha then which would not loose
> any functionality even for 32-bit binaries?

I don't think it is correct to think about 32-bit binaries on alpha.

Alpha never had a 32bit instruction set.  But at some point it looks
like binaries that could not handle more than 31 bits of address
space got ported and someone implemented a work-around.  I guess this
is the --taso option that Arnd mentioned.

I think the alpha version would look like:

#define SET_PERSONALITY(ex) 							\
	do {									\
		unsigned long personality = current->personality & ~PER_MASK;	\
                if ((EX).e_flags & EF_ALPHA_32BIT)				\
                	personality |= ADDR_LIMIT_32BIT;			\
		else								\
                	personality &= ~ADDR_LIMIT_32BIT			\
		set_personality(personality);					\
	while (0)

I do see code under arch/alpha/ testing ADDR_LIMIT_32BIT when
setting STACK_TOP, TASK_UNMAPPED_BASE, and arch_get_unmapped_area.
So I think the code still works.

>> In any case, I think we should fix alpha, mips and loongarch at
>> the same time, to make sure it doesn't take another decade to
>> fix the rest.
>
> If you're willing to fix all three at once, I would be happy to help
> with the testing on all three architectures as I have machines for all
> of these.

Yes getting those fixed would be nice.



I don't expect it is worth the hassle to remove support for
EF_ALPHA_32BIT, but I looked into it quickly.

I looked at the history to see if I could find any information about
what was using the EF_ALPHA_32BIT flag and unfortunately I could not
find anything.  Support for the flag first appeared the 2.1.86 release,
and the change description has been lost to time.

Does anyone know if there are any remaining alpha binaries that set
EF_ALPHA_32BIT?

If no interesting binaries have EF_ALPHA_32BIT set anymore
it might be worth using the generic SET_PERSONALITY and implementing
an arch_check_elf to just fail if one of those binaries show up.

Perhaps:
static inline int arch_check_elf(struct elfhdr *ehdr, bool has_interp,
				 struct elfhdr *interp_ehdr,
				 struct arch_elf_state *state)
{
        if (WARN_ON_ONCE(ehdr->e_flags & EF_ALPHA_32BIT)) {
        	return -ENOEXEC;
        }
	return 0;
}

Though frankly it might make more sense and go the other way.  I think
only mips has a non-trivial implementation of arch_check_elf.

Eric

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Arnd Bergmann]

On Thu, Jan 9, 2025, at 17:18, Eric W. Biederman wrote:
> John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:
>> On Thu, 2025-01-09 at 09:56 +0100, Arnd Bergmann wrote:
>>> On Thu, Jan 9, 2025, at 09:46, John Paul Adrian Glaubitz wrote:
>>> > On Thu, 2025-01-09 at 09:43 +0100, Arnd Bergmann wrote:
>>> > > On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
>>> > > > This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
>>> > > > PER_MASK, executing a regular binary from a taso binary no longer
>>> > > > reverts back to the entire 64-bit address space.
>>> > > > 
>>> > > > It seems that the behavior on most other architectures changed in 2012
>>> > > > commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
>>> > > > exec()").
>>> > > > 
>>> > 
>>> > So, if I understand this correctly, we should just use PER_MASK on alpha
>>> > for 64-bit executables and allow the bits to be cleared for 32-bit binaries?
>>> 
>>> I think ideally the EF_ALPHA_32BIT handling should use TIF_32BIT
>>> as we do on other architectures, at that point the custom SET_PERSONALITY()
>>> can be removed in favor of the asm-generic version.
>>
>> I have thought about that as well but I wasn't sure whether the extra
>> mangling on alpha was necessary.
>>
>>> Alternatively this could do something like the arm32 version (note
>>> that on arm, PER_LINUX_32BIT/ADDR_LIMIT_32BIT means "allow using
>>> the entire 32-bit address space rather than limiting to 26 bits for
>>> compatibility", while on alpha it means "use only 31 instead of
>>> 42 bits for addressing", but the logic can be the same):
>>> 
>>>         unsigned int personality = current->personality & ~PER_MASK;
>>>         /*
>>>          * APCS-26 is only valid for OABI executables
>>>          */
>>>         if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN &&
>>>             (eflags & EF_ARM_APCS_26))
>>>                 personality &= ~ADDR_LIMIT_32BIT;
>>>         else
>>>                 personality |= ADDR_LIMIT_32BIT;
>>>         set_personality(personality);
>>
>> So, this would be the 100% correct for alpha then which would not loose
>> any functionality even for 32-bit binaries?
>
> I don't think it is correct to think about 32-bit binaries on alpha.
>
> Alpha never had a 32bit instruction set.  But at some point it looks
> like binaries that could not handle more than 31 bits of address
> space got ported and someone implemented a work-around.  I guess this
> is the --taso option that Arnd mentioned.

There was a well-documented use case for taso with emulation for
OSF/1 a.out binaries, in particular Netscape used 32-bit pointers.
However, the a.out support got removed a while back, and I have
not figured out why it was ever added for ELF. Maybe it was just
easy to duplicate this from the a.out loader?

Obviously some 30 years ago it was common that software was
broken on 64-bit because of invalid integer-pointer casting,
but these days, it's much more common to be broken on 32-bit
instead.

> I think the alpha version would look like:
>
> #define SET_PERSONALITY(ex) 							\
> 	do {									\
> 		unsigned long personality = current->personality & ~PER_MASK;	\
>                 if ((EX).e_flags & EF_ALPHA_32BIT)				\
>                 	personality |= ADDR_LIMIT_32BIT;			\
> 		else								\
>                 	personality &= ~ADDR_LIMIT_32BIT			\
> 		set_personality(personality);					\
> 	while (0)

Yes, that was what I was suggesting.

> I do see code under arch/alpha/ testing ADDR_LIMIT_32BIT when
> setting STACK_TOP, TASK_UNMAPPED_BASE, and arch_get_unmapped_area.
> So I think the code still works.

MIPS introduced the SET_PERSONALITY2() macro specifically to
allow the TIF flags to be set early enough to apply to the
stack allocation, so I suspect it only works partially.

         Arnd

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Eric W. Biederman]

"Arnd Bergmann" <arnd@arndb.de> writes:

> On Thu, Jan 9, 2025, at 17:18, Eric W. Biederman wrote:
>> John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> writes:
>>> On Thu, 2025-01-09 at 09:56 +0100, Arnd Bergmann wrote:
>>>> On Thu, Jan 9, 2025, at 09:46, John Paul Adrian Glaubitz wrote:
>>>> > On Thu, 2025-01-09 at 09:43 +0100, Arnd Bergmann wrote:
>>>> > > On Thu, Jan 9, 2025, at 09:01, Arnd Bergmann wrote:
>>>> > > > This looks wrong to me: since ADDR_LIMIT_32BIT is not part of
>>>> > > > PER_MASK, executing a regular binary from a taso binary no longer
>>>> > > > reverts back to the entire 64-bit address space.
>>>> > > > 
>>>> > > > It seems that the behavior on most other architectures changed in 2012
>>>> > > > commit 16f3e95b3209 ("cross-arch: don't corrupt personality flags upon
>>>> > > > exec()").
>>>> > > > 
>>>> > 
>>>> > So, if I understand this correctly, we should just use PER_MASK on alpha
>>>> > for 64-bit executables and allow the bits to be cleared for 32-bit binaries?
>>>> 
>>>> I think ideally the EF_ALPHA_32BIT handling should use TIF_32BIT
>>>> as we do on other architectures, at that point the custom SET_PERSONALITY()
>>>> can be removed in favor of the asm-generic version.
>>>
>>> I have thought about that as well but I wasn't sure whether the extra
>>> mangling on alpha was necessary.
>>>
>>>> Alternatively this could do something like the arm32 version (note
>>>> that on arm, PER_LINUX_32BIT/ADDR_LIMIT_32BIT means "allow using
>>>> the entire 32-bit address space rather than limiting to 26 bits for
>>>> compatibility", while on alpha it means "use only 31 instead of
>>>> 42 bits for addressing", but the logic can be the same):
>>>> 
>>>>         unsigned int personality = current->personality & ~PER_MASK;
>>>>         /*
>>>>          * APCS-26 is only valid for OABI executables
>>>>          */
>>>>         if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN &&
>>>>             (eflags & EF_ARM_APCS_26))
>>>>                 personality &= ~ADDR_LIMIT_32BIT;
>>>>         else
>>>>                 personality |= ADDR_LIMIT_32BIT;
>>>>         set_personality(personality);
>>>
>>> So, this would be the 100% correct for alpha then which would not loose
>>> any functionality even for 32-bit binaries?
>>
>> I don't think it is correct to think about 32-bit binaries on alpha.
>>
>> Alpha never had a 32bit instruction set.  But at some point it looks
>> like binaries that could not handle more than 31 bits of address
>> space got ported and someone implemented a work-around.  I guess this
>> is the --taso option that Arnd mentioned.
>
> There was a well-documented use case for taso with emulation for
> OSF/1 a.out binaries, in particular Netscape used 32-bit pointers.
> However, the a.out support got removed a while back, and I have
> not figured out why it was ever added for ELF. Maybe it was just
> easy to duplicate this from the a.out loader?

It looks too well done to be just a duplication from the a.out loader.
Possibly OSF/1 was duplicating it from their a.out loader.

> Obviously some 30 years ago it was common that software was
> broken on 64-bit because of invalid integer-pointer casting,
> but these days, it's much more common to be broken on 32-bit
> instead.

Agreed.

>> I think the alpha version would look like:
>>
>> #define SET_PERSONALITY(ex) 							\
>> 	do {									\
>> 		unsigned long personality = current->personality & ~PER_MASK;	\
>>                 if ((EX).e_flags & EF_ALPHA_32BIT)				\
>>                 	personality |= ADDR_LIMIT_32BIT;			\
>> 		else								\
>>                 	personality &= ~ADDR_LIMIT_32BIT			\
>> 		set_personality(personality);					\
>> 	while (0)
>
> Yes, that was what I was suggesting.
>
>> I do see code under arch/alpha/ testing ADDR_LIMIT_32BIT when
>> setting STACK_TOP, TASK_UNMAPPED_BASE, and arch_get_unmapped_area.
>> So I think the code still works.
>
> MIPS introduced the SET_PERSONALITY2() macro specifically to
> allow the TIF flags to be set early enough to apply to the
> stack allocation, so I suspect it only works partially.

If you are in the personality flag you don't have the concern about
things being set early enough.  So I don't see anything that screams
this code is broken.

On the flip side if no one can think of any binaries that have that
EF_ALPHA_32BIT set in e_flags, it is totally reasonable to remove the
support from alpha and just have arch_check_elf fail (loudly) if such a
binary is encountered.  Then if someone cares the code can be added back
in.

Just removing the code is probably the easiest thing to do for long term
maintenance.  As then we are just maintaining the code people are using.

Eric

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Maciej W. Rozycki]

On Thu, 9 Jan 2025, Eric W. Biederman wrote:

> > So, this would be the 100% correct for alpha then which would not loose
> > any functionality even for 32-bit binaries?
> 
> I don't think it is correct to think about 32-bit binaries on alpha.
> 
> Alpha never had a 32bit instruction set.  But at some point it looks
> like binaries that could not handle more than 31 bits of address
> space got ported and someone implemented a work-around.  I guess this
> is the --taso option that Arnd mentioned.

 This also saves some code space in non-PIE and plain static executables 
as it takes fewer machine instructions to load a 64-bit address that is 
known beforehand to be a sign-extended 32-bit value.

 This is similar to the MIPS n32 ABI, which also implies a 32-bit address 
space while still using 64-bit registers for everything, starting from 
stack slots (it's also ILP32 with the `long long' C data type only making 
proper use of the full width of the CPU registers, while Alpha's --taso 
ABI is I believe IP32 (?) with the plain `long' C data type still 64-bit, 
just as with the regular LP64 ABI).

 This saving turned out quite important for some MIPS applications; less 
so for the Alpha, where indeed it was mainly a portability matter at the 
time when going beyond 32 bits (and writing clean code in the first place) 
was a big thing for some people.

  Maciej

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Arnd Bergmann]

On Thu, Jan 9, 2025, at 21:10, Maciej W. Rozycki wrote:
> On Thu, 9 Jan 2025, Eric W. Biederman wrote:
>
>> > So, this would be the 100% correct for alpha then which would not loose
>> > any functionality even for 32-bit binaries?
>> 
>> I don't think it is correct to think about 32-bit binaries on alpha.
>> 
>> Alpha never had a 32bit instruction set.  But at some point it looks
>> like binaries that could not handle more than 31 bits of address
>> space got ported and someone implemented a work-around.  I guess this
>> is the --taso option that Arnd mentioned.
>
>  This also saves some code space in non-PIE and plain static executables 
> as it takes fewer machine instructions to load a 64-bit address that is 
> known beforehand to be a sign-extended 32-bit value.
>
>  This is similar to the MIPS n32 ABI, which also implies a 32-bit address 
> space while still using 64-bit registers for everything, starting from 
> stack slots (it's also ILP32 with the `long long' C data type only making 
> proper use of the full width of the CPU registers, while Alpha's --taso 
> ABI is I believe IP32 (?) with the plain `long' C data type still 64-bit, 
> just as with the regular LP64 ABI).

I'm pretty sure it's still LP64 on Alpha Linux with gcc. There is an
-mpointer-size=32 option in gcc for VMS, but I don't see anything like
that in Linux. The only thing that is implemented here is the option
for the linker that sets the EF_ALPHA_32BIT bit, but none of the
code generation takes advantage of the upper bits being zero.

       Arnd

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Maciej W. Rozycki]

On Thu, 9 Jan 2025, Arnd Bergmann wrote:

> >  This is similar to the MIPS n32 ABI, which also implies a 32-bit address 
> > space while still using 64-bit registers for everything, starting from 
> > stack slots (it's also ILP32 with the `long long' C data type only making 
> > proper use of the full width of the CPU registers, while Alpha's --taso 
> > ABI is I believe IP32 (?) with the plain `long' C data type still 64-bit, 
> > just as with the regular LP64 ABI).
> 
> I'm pretty sure it's still LP64 on Alpha Linux with gcc. There is an
> -mpointer-size=32 option in gcc for VMS, but I don't see anything like
> that in Linux. The only thing that is implemented here is the option
> for the linker that sets the EF_ALPHA_32BIT bit, but none of the
> code generation takes advantage of the upper bits being zero.

 Pretty useless then nowadays (I knew about the option back in 1990s, 
though since forgot, and then never bothered to get into its details and 
considered cleaning up code instead a better use of resources).  Thanks 
for the explanation, and good riddance!

  Maciej

Re: [PATCH] alpha: Fix personality flag propagation across an exec

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Thu, 9 Jan 2025, 08:19 Eric W. Biederman, <ebiederm@xmission.com> wrote:

>
> I don't think it is correct to think about 32-bit binaries on alpha.
>
> Alpha never had a 32bit instruction set.  But at some point it looks
> like binaries that could not handle more than 31 bits of address
> space got ported and someone implemented a work-around.  I guess this
> is the --taso option that Arnd mentioned


It's worse than that.

There was a Spec benchmark (I forget which) which was memory bound and ran
twice as fast with 32-bit pointers.

I copied the idea from DEC to the ELF abi, but never did all the other work
to allow the toolchain to take advantage.

Amusingly, a later Spec changed the benchmark data sets to not fit into a
32-bit address space, specifically because of this.

I expect one could delete the ELF bit and personality and no one would
notice. Not even the 10 remaining Alpha users.

r~

[-- Attachment #2: Type: text/html, Size: 1550 bytes --]

[PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Eric W. Biederman]

Richard Henderson <richard.henderson@linaro.org> writes[1]:

> There was a Spec benchmark (I forget which) which was memory bound and ran
> twice as fast with 32-bit pointers.
>
> I copied the idea from DEC to the ELF abi, but never did all the other work
> to allow the toolchain to take advantage.
>
> Amusingly, a later Spec changed the benchmark data sets to not fit into a
> 32-bit address space, specifically because of this.
>
> I expect one could delete the ELF bit and personality and no one would
> notice. Not even the 10 remaining Alpha users.

In [2] it was pointed out that parts of setarch weren't working
properly on alpha because it has it's own SET_PERSONALITY
implementation.  In the discussion that followed Richard Henderson
pointed out that the 32bit pointer support for alpha was never
completed.

Fix this by removing alpha's 32bit pointer support.

As a bit of paranoia refuse to execute any alpha binaries that hafe
the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
somewhere has binaries that trying to use alpha's 32bit pointer
support.

[1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
[2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/alpha/include/asm/elf.h       |  6 +-----
 arch/alpha/include/asm/pgtable.h   |  2 +-
 arch/alpha/include/asm/processor.h |  8 ++------
 arch/alpha/kernel/osf_sys.c        | 11 ++---------
 4 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
index 4d7c46f50382..50c82187e60e 100644
--- a/arch/alpha/include/asm/elf.h
+++ b/arch/alpha/include/asm/elf.h
@@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
 /*
  * This is used to ensure we don't load something for the wrong architecture.
  */
-#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
+#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
 
 /*
  * These are used to set parameters in the core dumps.
@@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
 	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
 })
 
-#define SET_PERSONALITY(EX)					\
-	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
-	   ? PER_LINUX_32BIT : PER_LINUX)
-
 extern int alpha_l1i_cacheshape;
 extern int alpha_l1d_cacheshape;
 extern int alpha_l2_cacheshape;
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 635f0a5f5bbd..02e8817a8921 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
 
 extern void paging_init(void);
 
-/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
+/* We have our own get_unmapped_area */
 #define HAVE_ARCH_UNMAPPED_AREA
 
 #endif /* _ALPHA_PGTABLE_H */
diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
index 55bb1c09fd39..5dce5518a211 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -8,23 +8,19 @@
 #ifndef __ASM_ALPHA_PROCESSOR_H
 #define __ASM_ALPHA_PROCESSOR_H
 
-#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
-
 /*
  * We have a 42-bit user address space: 4TB user VM...
  */
 #define TASK_SIZE (0x40000000000UL)
 
-#define STACK_TOP \
-  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
+#define STACK_TOP (0x00120000000UL)
 
 #define STACK_TOP_MAX	0x00120000000UL
 
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */
-#define TASK_UNMAPPED_BASE \
-  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
+#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
 
 /* This is dead.  Everything has been moved to thread_info.  */
 struct thread_struct { };
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 86185021f75a..a08e8edef1a4 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
 	return ret;
 }
 
-/* Get an address range which is currently unmapped.  Similar to the
-   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
+/* Get an address range which is currently unmapped. */
 
 static unsigned long
 arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
@@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 		       unsigned long len, unsigned long pgoff,
 		       unsigned long flags, vm_flags_t vm_flags)
 {
-	unsigned long limit;
-
-	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
-	if (current->personality & ADDR_LIMIT_32BIT)
-		limit = 0x80000000;
-	else
-		limit = TASK_SIZE;
+	unsigned long limit = TASK_SIZE;
 
 	if (len > limit)
 		return -ENOMEM;
-- 
2.41.0

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Richard Henderson]

On 1/10/25 16:16, Eric W. Biederman wrote:
> 
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
> 
>> There was a Spec benchmark (I forget which) which was memory bound and ran
>> twice as fast with 32-bit pointers.
>>
>> I copied the idea from DEC to the ELF abi, but never did all the other work
>> to allow the toolchain to take advantage.
>>
>> Amusingly, a later Spec changed the benchmark data sets to not fit into a
>> 32-bit address space, specifically because of this.
>>
>> I expect one could delete the ELF bit and personality and no one would
>> notice. Not even the 10 remaining Alpha users.
> 
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation.  In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
> 
> Fix this by removing alpha's 32bit pointer support.
> 
> As a bit of paranoia refuse to execute any alpha binaries that hafe
> the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> somewhere has binaries that trying to use alpha's 32bit pointer
> support.
> 
> [1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

Thanks for cleaning this up.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~


> ---
>   arch/alpha/include/asm/elf.h       |  6 +-----
>   arch/alpha/include/asm/pgtable.h   |  2 +-
>   arch/alpha/include/asm/processor.h |  8 ++------
>   arch/alpha/kernel/osf_sys.c        | 11 ++---------
>   4 files changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..50c82187e60e 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>   /*
>    * This is used to ensure we don't load something for the wrong architecture.
>    */
> -#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
> +#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
>   
>   /*
>    * These are used to set parameters in the core dumps.
> @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
>   	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
>   })
>   
> -#define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> -
>   extern int alpha_l1i_cacheshape;
>   extern int alpha_l1d_cacheshape;
>   extern int alpha_l2_cacheshape;
> diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
> index 635f0a5f5bbd..02e8817a8921 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>   
>   extern void paging_init(void);
>   
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> +/* We have our own get_unmapped_area */
>   #define HAVE_ARCH_UNMAPPED_AREA
>   
>   #endif /* _ALPHA_PGTABLE_H */
> diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
> index 55bb1c09fd39..5dce5518a211 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -8,23 +8,19 @@
>   #ifndef __ASM_ALPHA_PROCESSOR_H
>   #define __ASM_ALPHA_PROCESSOR_H
>   
> -#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
> -
>   /*
>    * We have a 42-bit user address space: 4TB user VM...
>    */
>   #define TASK_SIZE (0x40000000000UL)
>   
> -#define STACK_TOP \
> -  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
> +#define STACK_TOP (0x00120000000UL)
>   
>   #define STACK_TOP_MAX	0x00120000000UL
>   
>   /* This decides where the kernel will search for a free chunk of vm
>    * space during mmap's.
>    */
> -#define TASK_UNMAPPED_BASE \
> -  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
> +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
>   
>   /* This is dead.  Everything has been moved to thread_info.  */
>   struct thread_struct { };
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 86185021f75a..a08e8edef1a4 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
>   	return ret;
>   }
>   
> -/* Get an address range which is currently unmapped.  Similar to the
> -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> +/* Get an address range which is currently unmapped. */
>   
>   static unsigned long
>   arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>   		       unsigned long len, unsigned long pgoff,
>   		       unsigned long flags, vm_flags_t vm_flags)
>   {
> -	unsigned long limit;
> -
> -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> -	if (current->personality & ADDR_LIMIT_32BIT)
> -		limit = 0x80000000;
> -	else
> -		limit = TASK_SIZE;
> +	unsigned long limit = TASK_SIZE;
>   
>   	if (len > limit)
>   		return -ENOMEM;

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[John Paul Adrian Glaubitz]

Hi Eric,

On Fri, 2025-01-10 at 18:16 -0600, Eric W. Biederman wrote:
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
> 
> > There was a Spec benchmark (I forget which) which was memory bound and ran
> > twice as fast with 32-bit pointers.
> > 
> > I copied the idea from DEC to the ELF abi, but never did all the other work
> > to allow the toolchain to take advantage.
> > 
> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
> > 32-bit address space, specifically because of this.
> > 
> > I expect one could delete the ELF bit and personality and no one would
> > notice. Not even the 10 remaining Alpha users.
> 
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation.  In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
> 
> Fix this by removing alpha's 32bit pointer support.
> 
> As a bit of paranoia refuse to execute any alpha binaries that hafe
                                                                 ^^^^ hafe->have

> the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> somewhere has binaries that trying to use alpha's 32bit pointer
                            ^^^ are

> support.
> 
> [1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>  arch/alpha/include/asm/elf.h       |  6 +-----
>  arch/alpha/include/asm/pgtable.h   |  2 +-
>  arch/alpha/include/asm/processor.h |  8 ++------
>  arch/alpha/kernel/osf_sys.c        | 11 ++---------
>  4 files changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..50c82187e60e 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>  /*
>   * This is used to ensure we don't load something for the wrong architecture.
>   */
> -#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
> +#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
>  
>  /*
>   * These are used to set parameters in the core dumps.
> @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
>  	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
>  })
>  
> -#define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> -
>  extern int alpha_l1i_cacheshape;
>  extern int alpha_l1d_cacheshape;
>  extern int alpha_l2_cacheshape;
> diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
> index 635f0a5f5bbd..02e8817a8921 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>  
>  extern void paging_init(void);
>  
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> +/* We have our own get_unmapped_area */
>  #define HAVE_ARCH_UNMAPPED_AREA
>  
>  #endif /* _ALPHA_PGTABLE_H */
> diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
> index 55bb1c09fd39..5dce5518a211 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -8,23 +8,19 @@
>  #ifndef __ASM_ALPHA_PROCESSOR_H
>  #define __ASM_ALPHA_PROCESSOR_H
>  
> -#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
> -
>  /*
>   * We have a 42-bit user address space: 4TB user VM...
>   */
>  #define TASK_SIZE (0x40000000000UL)
>  
> -#define STACK_TOP \
> -  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
> +#define STACK_TOP (0x00120000000UL)
>  
>  #define STACK_TOP_MAX	0x00120000000UL
>  
>  /* This decides where the kernel will search for a free chunk of vm
>   * space during mmap's.
>   */
> -#define TASK_UNMAPPED_BASE \
> -  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
> +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
>  
>  /* This is dead.  Everything has been moved to thread_info.  */
>  struct thread_struct { };
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 86185021f75a..a08e8edef1a4 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
>  	return ret;
>  }
>  
> -/* Get an address range which is currently unmapped.  Similar to the
> -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> +/* Get an address range which is currently unmapped. */
>  
>  static unsigned long
>  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>  		       unsigned long len, unsigned long pgoff,
>  		       unsigned long flags, vm_flags_t vm_flags)
>  {
> -	unsigned long limit;
> -
> -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> -	if (current->personality & ADDR_LIMIT_32BIT)
> -		limit = 0x80000000;
> -	else
> -		limit = TASK_SIZE;
> +	unsigned long limit = TASK_SIZE;
>  
>  	if (len > limit)
>  		return -ENOMEM;

Looks good to me besides the two spelling mistakes above in the comment.

Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Will also test and report back shortly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Maciej W. Rozycki]

On Sat, 11 Jan 2025, John Paul Adrian Glaubitz wrote:

> > the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> > somewhere has binaries that trying to use alpha's 32bit pointer
>                             ^^^ are

 If nitpicking, I'd say just "try".

  Maciej

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[John Paul Adrian Glaubitz]

On Sun, 2025-01-12 at 14:40 +0000, Maciej W. Rozycki wrote:
> On Sat, 11 Jan 2025, John Paul Adrian Glaubitz wrote:
> 
> > > the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> > > somewhere has binaries that trying to use alpha's 32bit pointer
> >                             ^^^ are
> 
>  If nitpicking, I'd say just "try".

No objection. I was just hinting at obvious grammar mistakes. ;-)

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Eric W. Biederman]

Richard Henderson <richard.henderson@linaro.org> writes[1]:

> There was a Spec benchmark (I forget which) which was memory bound and ran
> twice as fast with 32-bit pointers.
>
> I copied the idea from DEC to the ELF abi, but never did all the other work
> to allow the toolchain to take advantage.
>
> Amusingly, a later Spec changed the benchmark data sets to not fit into a
> 32-bit address space, specifically because of this.
>
> I expect one could delete the ELF bit and personality and no one would
> notice. Not even the 10 remaining Alpha users.

In [2] it was pointed out that parts of setarch weren't working
properly on alpha because it has it's own SET_PERSONALITY
implementation.  In the discussion that followed Richard Henderson
pointed out that the 32bit pointer support for alpha was never
completed.

Fix this by removing alpha's 32bit pointer support.

As a bit of paranoia refuse to execute any alpha binaries that have
the EF_ALPHA_32BIT flag set.  Just in case someone somewhere has
binaries that try to use alpha's 32bit pointer support.

[1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
[2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
v1: https://lkml.kernel.org/r/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---

Kees can you pick this one up?

 arch/alpha/include/asm/elf.h       |  6 +-----
 arch/alpha/include/asm/pgtable.h   |  2 +-
 arch/alpha/include/asm/processor.h |  8 ++------
 arch/alpha/kernel/osf_sys.c        | 11 ++---------
 4 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
index 4d7c46f50382..50c82187e60e 100644
--- a/arch/alpha/include/asm/elf.h
+++ b/arch/alpha/include/asm/elf.h
@@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
 /*
  * This is used to ensure we don't load something for the wrong architecture.
  */
-#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
+#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
 
 /*
  * These are used to set parameters in the core dumps.
@@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
 	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
 })
 
-#define SET_PERSONALITY(EX)					\
-	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
-	   ? PER_LINUX_32BIT : PER_LINUX)
-
 extern int alpha_l1i_cacheshape;
 extern int alpha_l1d_cacheshape;
 extern int alpha_l2_cacheshape;
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 635f0a5f5bbd..02e8817a8921 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
 
 extern void paging_init(void);
 
-/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
+/* We have our own get_unmapped_area */
 #define HAVE_ARCH_UNMAPPED_AREA
 
 #endif /* _ALPHA_PGTABLE_H */
diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
index 55bb1c09fd39..5dce5518a211 100644
--- a/arch/alpha/include/asm/processor.h
+++ b/arch/alpha/include/asm/processor.h
@@ -8,23 +8,19 @@
 #ifndef __ASM_ALPHA_PROCESSOR_H
 #define __ASM_ALPHA_PROCESSOR_H
 
-#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
-
 /*
  * We have a 42-bit user address space: 4TB user VM...
  */
 #define TASK_SIZE (0x40000000000UL)
 
-#define STACK_TOP \
-  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
+#define STACK_TOP (0x00120000000UL)
 
 #define STACK_TOP_MAX	0x00120000000UL
 
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
  */
-#define TASK_UNMAPPED_BASE \
-  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
+#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
 
 /* This is dead.  Everything has been moved to thread_info.  */
 struct thread_struct { };
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 86185021f75a..a08e8edef1a4 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
 	return ret;
 }
 
-/* Get an address range which is currently unmapped.  Similar to the
-   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
+/* Get an address range which is currently unmapped. */
 
 static unsigned long
 arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
@@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 		       unsigned long len, unsigned long pgoff,
 		       unsigned long flags, vm_flags_t vm_flags)
 {
-	unsigned long limit;
-
-	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
-	if (current->personality & ADDR_LIMIT_32BIT)
-		limit = 0x80000000;
-	else
-		limit = TASK_SIZE;
+	unsigned long limit = TASK_SIZE;
 
 	if (len > limit)
 		return -ENOMEM;
-- 
2.41.0

Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Ivan Kokshaysky]

On Sun, Jan 12, 2025 at 11:39:01PM -0600, Eric W. Biederman wrote:
...
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>  
>  extern void paging_init(void);
>  
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> +/* We have our own get_unmapped_area */
>  #define HAVE_ARCH_UNMAPPED_AREA

Just remove the definition. As the comment suggests, the only reason
it exists is ADDR_LIMIT_32BIT, which is gone.

> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
>  	return ret;
>  }
>  
> -/* Get an address range which is currently unmapped.  Similar to the
> -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> +/* Get an address range which is currently unmapped. */
>  
>  static unsigned long
>  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>  		       unsigned long len, unsigned long pgoff,
>  		       unsigned long flags, vm_flags_t vm_flags)
>  {
> -	unsigned long limit;
> -
> -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> -	if (current->personality & ADDR_LIMIT_32BIT)
> -		limit = 0x80000000;
> -	else
> -		limit = TASK_SIZE;
> +	unsigned long limit = TASK_SIZE;
>  
>  	if (len > limit)
>  		return -ENOMEM;

Likewise, just remove these functions. The generic_get_unmapped_area()
works fine, tested on up1500.

Ivan.

Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[John Paul Adrian Glaubitz]

Hi Eric,

On Sat, 2025-01-18 at 11:35 +0100, Ivan Kokshaysky wrote:
> On Sun, Jan 12, 2025 at 11:39:01PM -0600, Eric W. Biederman wrote:
> ...
> > --- a/arch/alpha/include/asm/pgtable.h
> > +++ b/arch/alpha/include/asm/pgtable.h
> > @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> >  
> >  extern void paging_init(void);
> >  
> > -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> > +/* We have our own get_unmapped_area */
> >  #define HAVE_ARCH_UNMAPPED_AREA
> 
> Just remove the definition. As the comment suggests, the only reason
> it exists is ADDR_LIMIT_32BIT, which is gone.
> 
> > --- a/arch/alpha/kernel/osf_sys.c
> > +++ b/arch/alpha/kernel/osf_sys.c
> > @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
> >  	return ret;
> >  }
> >  
> > -/* Get an address range which is currently unmapped.  Similar to the
> > -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> > +/* Get an address range which is currently unmapped. */
> >  
> >  static unsigned long
> >  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> > @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
> >  		       unsigned long len, unsigned long pgoff,
> >  		       unsigned long flags, vm_flags_t vm_flags)
> >  {
> > -	unsigned long limit;
> > -
> > -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> > -	if (current->personality & ADDR_LIMIT_32BIT)
> > -		limit = 0x80000000;
> > -	else
> > -		limit = TASK_SIZE;
> > +	unsigned long limit = TASK_SIZE;
> >  
> >  	if (len > limit)
> >  		return -ENOMEM;
> 
> Likewise, just remove these functions. The generic_get_unmapped_area()
> works fine, tested on up1500.

Can you send a follow-up integrating those changes? It would be good if
SET_PERSONALITY() could be fixed on alpha for v6.14.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Ivan Kokshaysky]

On Sun, Jan 26, 2025 at 06:15:43PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Eric,
> 
> On Sat, 2025-01-18 at 11:35 +0100, Ivan Kokshaysky wrote:
> > On Sun, Jan 12, 2025 at 11:39:01PM -0600, Eric W. Biederman wrote:
> > ...
> > > --- a/arch/alpha/include/asm/pgtable.h
> > > +++ b/arch/alpha/include/asm/pgtable.h
> > > @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> > >  
> > >  extern void paging_init(void);
> > >  
> > > -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> > > +/* We have our own get_unmapped_area */
> > >  #define HAVE_ARCH_UNMAPPED_AREA
> > 
> > Just remove the definition. As the comment suggests, the only reason
> > it exists is ADDR_LIMIT_32BIT, which is gone.
> > 
> > > --- a/arch/alpha/kernel/osf_sys.c
> > > +++ b/arch/alpha/kernel/osf_sys.c
> > > @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
> > >  	return ret;
> > >  }
> > >  
> > > -/* Get an address range which is currently unmapped.  Similar to the
> > > -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> > > +/* Get an address range which is currently unmapped. */
> > >  
> > >  static unsigned long
> > >  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> > > @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
> > >  		       unsigned long len, unsigned long pgoff,
> > >  		       unsigned long flags, vm_flags_t vm_flags)
> > >  {
> > > -	unsigned long limit;
> > > -
> > > -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> > > -	if (current->personality & ADDR_LIMIT_32BIT)
> > > -		limit = 0x80000000;
> > > -	else
> > > -		limit = TASK_SIZE;
> > > +	unsigned long limit = TASK_SIZE;
> > >  
> > >  	if (len > limit)
> > >  		return -ENOMEM;
> > 
> > Likewise, just remove these functions. The generic_get_unmapped_area()
> > works fine, tested on up1500.
> 
> Can you send a follow-up integrating those changes? It would be good if
> SET_PERSONALITY() could be fixed on alpha for v6.14.

Oh, the changes I proposed are mere cleanup suggestions.
The original patch would do just fine.

Ivan.

Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[John Paul Adrian Glaubitz]

Hi,

On Sun, 2025-01-12 at 23:39 -0600, Eric W. Biederman wrote:
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
> 
> > There was a Spec benchmark (I forget which) which was memory bound and ran
> > twice as fast with 32-bit pointers.
> > 
> > I copied the idea from DEC to the ELF abi, but never did all the other work
> > to allow the toolchain to take advantage.
> > 
> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
> > 32-bit address space, specifically because of this.
> > 
> > I expect one could delete the ELF bit and personality and no one would
> > notice. Not even the 10 remaining Alpha users.
> 
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation.  In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
> 
> Fix this by removing alpha's 32bit pointer support.
> 
> As a bit of paranoia refuse to execute any alpha binaries that have
> the EF_ALPHA_32BIT flag set.  Just in case someone somewhere has
> binaries that try to use alpha's 32bit pointer support.
> 
> [1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> v1: https://lkml.kernel.org/r/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> 
> Kees can you pick this one up?
> 
>  arch/alpha/include/asm/elf.h       |  6 +-----
>  arch/alpha/include/asm/pgtable.h   |  2 +-
>  arch/alpha/include/asm/processor.h |  8 ++------
>  arch/alpha/kernel/osf_sys.c        | 11 ++---------
>  4 files changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..50c82187e60e 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>  /*
>   * This is used to ensure we don't load something for the wrong architecture.
>   */
> -#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
> +#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
>  
>  /*
>   * These are used to set parameters in the core dumps.
> @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
>  	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
>  })
>  
> -#define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> -
>  extern int alpha_l1i_cacheshape;
>  extern int alpha_l1d_cacheshape;
>  extern int alpha_l2_cacheshape;
> diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
> index 635f0a5f5bbd..02e8817a8921 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>  
>  extern void paging_init(void);
>  
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> +/* We have our own get_unmapped_area */
>  #define HAVE_ARCH_UNMAPPED_AREA
>  
>  #endif /* _ALPHA_PGTABLE_H */
> diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
> index 55bb1c09fd39..5dce5518a211 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -8,23 +8,19 @@
>  #ifndef __ASM_ALPHA_PROCESSOR_H
>  #define __ASM_ALPHA_PROCESSOR_H
>  
> -#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
> -
>  /*
>   * We have a 42-bit user address space: 4TB user VM...
>   */
>  #define TASK_SIZE (0x40000000000UL)
>  
> -#define STACK_TOP \
> -  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
> +#define STACK_TOP (0x00120000000UL)
>  
>  #define STACK_TOP_MAX	0x00120000000UL
>  
>  /* This decides where the kernel will search for a free chunk of vm
>   * space during mmap's.
>   */
> -#define TASK_UNMAPPED_BASE \
> -  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
> +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
>  
>  /* This is dead.  Everything has been moved to thread_info.  */
>  struct thread_struct { };
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 86185021f75a..a08e8edef1a4 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
>  	return ret;
>  }
>  
> -/* Get an address range which is currently unmapped.  Similar to the
> -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> +/* Get an address range which is currently unmapped. */
>  
>  static unsigned long
>  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>  		       unsigned long len, unsigned long pgoff,
>  		       unsigned long flags, vm_flags_t vm_flags)
>  {
> -	unsigned long limit;
> -
> -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> -	if (current->personality & ADDR_LIMIT_32BIT)
> -		limit = 0x80000000;
> -	else
> -		limit = TASK_SIZE;
> +	unsigned long limit = TASK_SIZE;
>  
>  	if (len > limit)
>  		return -ENOMEM;

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Can someone pick up this patch for v6.14?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v2] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Kees Cook]

On Sun, 12 Jan 2025 23:39:01 -0600, Eric W. Biederman wrote:
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
> 
> > There was a Spec benchmark (I forget which) which was memory bound and ran
> > twice as fast with 32-bit pointers.
> >
> > I copied the idea from DEC to the ELF abi, but never did all the other work
> > to allow the toolchain to take advantage.
> >
> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
> > 32-bit address space, specifically because of this.
> >
> > I expect one could delete the ELF bit and personality and no one would
> > notice. Not even the 10 remaining Alpha users.
> 
> [...]

Applied to for-next/topic/execve/core, thanks!

[1/1] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
      https://git.kernel.org/kees/c/b029628be267

Take care,

-- 
Kees Cook

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Arnd Bergmann]

On Sat, Jan 11, 2025, at 01:16, Eric W. Biederman wrote:
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
>
>> There was a Spec benchmark (I forget which) which was memory bound and ran
>> twice as fast with 32-bit pointers.
>>
>> I copied the idea from DEC to the ELF abi, but never did all the other work
>> to allow the toolchain to take advantage.
>>
>> Amusingly, a later Spec changed the benchmark data sets to not fit into a
>> 32-bit address space, specifically because of this.
>>
>> I expect one could delete the ELF bit and personality and no one would
>> notice. Not even the 10 remaining Alpha users.
>
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation.  In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
>
> Fix this by removing alpha's 32bit pointer support.
>
> As a bit of paranoia refuse to execute any alpha binaries that hafe
> the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> somewhere has binaries that trying to use alpha's 32bit pointer
> support.
>
> [1] 
> https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] 
> https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Ivan Kokshaysky]

On Fri, Jan 10, 2025 at 06:16:28PM -0600, Eric W. Biederman wrote:
> 
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
> 
> > There was a Spec benchmark (I forget which) which was memory bound and ran
> > twice as fast with 32-bit pointers.
> >
> > I copied the idea from DEC to the ELF abi, but never did all the other work
> > to allow the toolchain to take advantage.
> >
> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
> > 32-bit address space, specifically because of this.
> >
> > I expect one could delete the ELF bit and personality and no one would
> > notice. Not even the 10 remaining Alpha users.
> 
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation.  In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
> 
> Fix this by removing alpha's 32bit pointer support.
> 
> As a bit of paranoia refuse to execute any alpha binaries that hafe
> the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> somewhere has binaries that trying to use alpha's 32bit pointer
> support.

In general I agree, but then someone ought to remove the "--taso" option
from GNU ld, which produces such binaries.

Ivan.

> [1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>  arch/alpha/include/asm/elf.h       |  6 +-----
>  arch/alpha/include/asm/pgtable.h   |  2 +-
>  arch/alpha/include/asm/processor.h |  8 ++------
>  arch/alpha/kernel/osf_sys.c        | 11 ++---------
>  4 files changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..50c82187e60e 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>  /*
>   * This is used to ensure we don't load something for the wrong architecture.
>   */
> -#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
> +#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
>  
>  /*
>   * These are used to set parameters in the core dumps.
> @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
>  	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
>  })
>  
> -#define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> -
>  extern int alpha_l1i_cacheshape;
>  extern int alpha_l1d_cacheshape;
>  extern int alpha_l2_cacheshape;
> diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
> index 635f0a5f5bbd..02e8817a8921 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>  
>  extern void paging_init(void);
>  
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> +/* We have our own get_unmapped_area */
>  #define HAVE_ARCH_UNMAPPED_AREA
>  
>  #endif /* _ALPHA_PGTABLE_H */
> diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
> index 55bb1c09fd39..5dce5518a211 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -8,23 +8,19 @@
>  #ifndef __ASM_ALPHA_PROCESSOR_H
>  #define __ASM_ALPHA_PROCESSOR_H
>  
> -#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
> -
>  /*
>   * We have a 42-bit user address space: 4TB user VM...
>   */
>  #define TASK_SIZE (0x40000000000UL)
>  
> -#define STACK_TOP \
> -  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
> +#define STACK_TOP (0x00120000000UL)
>  
>  #define STACK_TOP_MAX	0x00120000000UL
>  
>  /* This decides where the kernel will search for a free chunk of vm
>   * space during mmap's.
>   */
> -#define TASK_UNMAPPED_BASE \
> -  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
> +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
>  
>  /* This is dead.  Everything has been moved to thread_info.  */
>  struct thread_struct { };
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 86185021f75a..a08e8edef1a4 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
>  	return ret;
>  }
>  
> -/* Get an address range which is currently unmapped.  Similar to the
> -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> +/* Get an address range which is currently unmapped. */
>  
>  static unsigned long
>  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>  		       unsigned long len, unsigned long pgoff,
>  		       unsigned long flags, vm_flags_t vm_flags)
>  {
> -	unsigned long limit;
> -
> -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> -	if (current->personality & ADDR_LIMIT_32BIT)
> -		limit = 0x80000000;
> -	else
> -		limit = TASK_SIZE;
> +	unsigned long limit = TASK_SIZE;
>  
>  	if (len > limit)
>  		return -ENOMEM;
> -- 
> 2.41.0
> 
> 

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[Eric W. Biederman]

Ivan Kokshaysky <ink@unseen.parts> writes:

> On Fri, Jan 10, 2025 at 06:16:28PM -0600, Eric W. Biederman wrote:
>> 
>> Richard Henderson <richard.henderson@linaro.org> writes[1]:
>> 
>> > There was a Spec benchmark (I forget which) which was memory bound and ran
>> > twice as fast with 32-bit pointers.
>> >
>> > I copied the idea from DEC to the ELF abi, but never did all the other work
>> > to allow the toolchain to take advantage.
>> >
>> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
>> > 32-bit address space, specifically because of this.
>> >
>> > I expect one could delete the ELF bit and personality and no one would
>> > notice. Not even the 10 remaining Alpha users.
>> 
>> In [2] it was pointed out that parts of setarch weren't working
>> properly on alpha because it has it's own SET_PERSONALITY
>> implementation.  In the discussion that followed Richard Henderson
>> pointed out that the 32bit pointer support for alpha was never
>> completed.
>> 
>> Fix this by removing alpha's 32bit pointer support.
>> 
>> As a bit of paranoia refuse to execute any alpha binaries that hafe
>> the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
>> somewhere has binaries that trying to use alpha's 32bit pointer
>> support.
>
> In general I agree, but then someone ought to remove the "--taso" option
> from GNU ld, which produces such binaries.

Please feel free to write such a patch.  I don't know the GNU ld process
well enough to write that patch.

It would be good to remove dead code and confusing code from GNU ld,
as well as from the linux kernel.

Eric

Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support

[John Paul Adrian Glaubitz]

Hi Eric,

On Fri, 2025-01-10 at 18:16 -0600, Eric W. Biederman wrote:
> Richard Henderson <richard.henderson@linaro.org> writes[1]:
> 
> > There was a Spec benchmark (I forget which) which was memory bound and ran
> > twice as fast with 32-bit pointers.
> > 
> > I copied the idea from DEC to the ELF abi, but never did all the other work
> > to allow the toolchain to take advantage.
> > 
> > Amusingly, a later Spec changed the benchmark data sets to not fit into a
> > 32-bit address space, specifically because of this.
> > 
> > I expect one could delete the ELF bit and personality and no one would
> > notice. Not even the 10 remaining Alpha users.
> 
> In [2] it was pointed out that parts of setarch weren't working
> properly on alpha because it has it's own SET_PERSONALITY
> implementation.  In the discussion that followed Richard Henderson
> pointed out that the 32bit pointer support for alpha was never
> completed.
> 
> Fix this by removing alpha's 32bit pointer support.
> 
> As a bit of paranoia refuse to execute any alpha binaries that hafe
> the EF_ALPHA_32BIT flag set.  Just to fail explicitly in case someone
> somewhere has binaries that trying to use alpha's 32bit pointer
> support.
> 
> [1] https://lkml.kernel.org/r/CAFXwXrkgu=4Qn-v1PjnOR4SG0oUb9LSa0g6QXpBq4ttm52pJOQ@mail.gmail.com
> [2] https://lkml.kernel.org/r/20250103140148.370368-1-glaubitz@physik.fu-berlin.de
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>  arch/alpha/include/asm/elf.h       |  6 +-----
>  arch/alpha/include/asm/pgtable.h   |  2 +-
>  arch/alpha/include/asm/processor.h |  8 ++------
>  arch/alpha/kernel/osf_sys.c        | 11 ++---------
>  4 files changed, 6 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/elf.h b/arch/alpha/include/asm/elf.h
> index 4d7c46f50382..50c82187e60e 100644
> --- a/arch/alpha/include/asm/elf.h
> +++ b/arch/alpha/include/asm/elf.h
> @@ -74,7 +74,7 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>  /*
>   * This is used to ensure we don't load something for the wrong architecture.
>   */
> -#define elf_check_arch(x) ((x)->e_machine == EM_ALPHA)
> +#define elf_check_arch(x) (((x)->e_machine == EM_ALPHA) && !((x)->e_flags & EF_ALPHA_32BIT))
>  
>  /*
>   * These are used to set parameters in the core dumps.
> @@ -137,10 +137,6 @@ extern int dump_elf_task(elf_greg_t *dest, struct task_struct *task);
>  	: amask (AMASK_CIX) ? "ev6" : "ev67");	\
>  })
>  
> -#define SET_PERSONALITY(EX)					\
> -	set_personality(((EX).e_flags & EF_ALPHA_32BIT)		\
> -	   ? PER_LINUX_32BIT : PER_LINUX)
> -
>  extern int alpha_l1i_cacheshape;
>  extern int alpha_l1d_cacheshape;
>  extern int alpha_l2_cacheshape;
> diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
> index 635f0a5f5bbd..02e8817a8921 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -360,7 +360,7 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>  
>  extern void paging_init(void);
>  
> -/* We have our own get_unmapped_area to cope with ADDR_LIMIT_32BIT.  */
> +/* We have our own get_unmapped_area */
>  #define HAVE_ARCH_UNMAPPED_AREA
>  
>  #endif /* _ALPHA_PGTABLE_H */
> diff --git a/arch/alpha/include/asm/processor.h b/arch/alpha/include/asm/processor.h
> index 55bb1c09fd39..5dce5518a211 100644
> --- a/arch/alpha/include/asm/processor.h
> +++ b/arch/alpha/include/asm/processor.h
> @@ -8,23 +8,19 @@
>  #ifndef __ASM_ALPHA_PROCESSOR_H
>  #define __ASM_ALPHA_PROCESSOR_H
>  
> -#include <linux/personality.h>	/* for ADDR_LIMIT_32BIT */
> -
>  /*
>   * We have a 42-bit user address space: 4TB user VM...
>   */
>  #define TASK_SIZE (0x40000000000UL)
>  
> -#define STACK_TOP \
> -  (current->personality & ADDR_LIMIT_32BIT ? 0x80000000 : 0x00120000000UL)
> +#define STACK_TOP (0x00120000000UL)
>  
>  #define STACK_TOP_MAX	0x00120000000UL
>  
>  /* This decides where the kernel will search for a free chunk of vm
>   * space during mmap's.
>   */
> -#define TASK_UNMAPPED_BASE \
> -  ((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
> +#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
>  
>  /* This is dead.  Everything has been moved to thread_info.  */
>  struct thread_struct { };
> diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
> index 86185021f75a..a08e8edef1a4 100644
> --- a/arch/alpha/kernel/osf_sys.c
> +++ b/arch/alpha/kernel/osf_sys.c
> @@ -1210,8 +1210,7 @@ SYSCALL_DEFINE1(old_adjtimex, struct timex32 __user *, txc_p)
>  	return ret;
>  }
>  
> -/* Get an address range which is currently unmapped.  Similar to the
> -   generic version except that we know how to honor ADDR_LIMIT_32BIT.  */
> +/* Get an address range which is currently unmapped. */
>  
>  static unsigned long
>  arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
> @@ -1230,13 +1229,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>  		       unsigned long len, unsigned long pgoff,
>  		       unsigned long flags, vm_flags_t vm_flags)
>  {
> -	unsigned long limit;
> -
> -	/* "32 bit" actually means 31 bit, since pointers sign extend.  */
> -	if (current->personality & ADDR_LIMIT_32BIT)
> -		limit = 0x80000000;
> -	else
> -		limit = TASK_SIZE;
> +	unsigned long limit = TASK_SIZE;
>  
>  	if (len > limit)
>  		return -ENOMEM;

Compile- and boot-tested on QEMU alpha, works as expected:

glaubitz@debian-alpha:~/util-linux$ ./tests/ts/misc/setarch 
         misc: setarch                        ...
                : options                     ...[  110.194279] pid=558, couldn't seal address 0, ret=-12.
 OK
                : uname26                     ... OK
                : uname26-version             ... OK
                : show                        ... OK
           ... OK (all 4 sub-tests PASSED)
glaubitz@debian-alpha:~/util-linux$

Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913