All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Kokshaysky <ink@unseen.parts>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Arnd Bergmann <arnd@arndb.de>,
	Richard Henderson <richard.henderson@linaro.org>,
	Matt Turner <mattst88@gmail.com>, Kees Cook <kees@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	linux-alpha@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Michael Cree <mcree@orcon.net.nz>,
	Sam James <sam@gentoo.org>,
	"Maciej W. Rozycki" <macro@orcam.me.uk>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>,
	Chris Hofstaedtler <zeha@debian.org>,
	util-linux@vger.kernel.org, linux-mips@vger.kernel.org,
	loongarch@lists.linux.dev
Subject: Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
Date: Sat, 11 Jan 2025 16:27:57 +0100	[thread overview]
Message-ID: <Z4KN_aOT6uZRAm8a@minute> (raw)
In-Reply-To: <87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org>

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

  parent reply	other threads:[~2025-01-11 15:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-03 14:01 [PATCH] alpha: Fix personality flag propagation across an exec John Paul Adrian Glaubitz
2025-01-08 22:49 ` Kees Cook
2025-01-09  0:52   ` Jeff Xu
2025-01-09  8:01 ` Arnd Bergmann
2025-01-09  8:43   ` Arnd Bergmann
2025-01-09  8:46     ` John Paul Adrian Glaubitz
2025-01-09  8:56       ` Arnd Bergmann
2025-01-09  9:12         ` John Paul Adrian Glaubitz
2025-01-09 16:18           ` Eric W. Biederman
2025-01-09 16:52             ` Arnd Bergmann
2025-01-09 17:17               ` Eric W. Biederman
2025-01-09 20:10             ` Maciej W. Rozycki
2025-01-09 20:53               ` Arnd Bergmann
2025-01-12 14:40                 ` Maciej W. Rozycki
2025-01-10  0:28             ` Richard Henderson
2025-01-11  0:16           ` [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support Eric W. Biederman
2025-01-11  1:17             ` Richard Henderson
2025-01-11 10:37             ` John Paul Adrian Glaubitz
2025-01-12 14:40               ` Maciej W. Rozycki
2025-01-12 14:56                 ` John Paul Adrian Glaubitz
2025-01-13  5:39                   ` [PATCH v2] " Eric W. Biederman
2025-01-18 10:35                     ` Ivan Kokshaysky
2025-01-26 17:15                       ` John Paul Adrian Glaubitz
2025-01-27 13:27                         ` Ivan Kokshaysky
2025-02-03 11:55                     ` John Paul Adrian Glaubitz
2025-02-06 15:42                     ` Kees Cook
2025-01-11 11:26             ` [PATCH] " Arnd Bergmann
2025-01-11 15:27             ` Ivan Kokshaysky [this message]
2025-01-13  5:32               ` Eric W. Biederman
2025-01-11 21:26             ` John Paul Adrian Glaubitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z4KN_aOT6uZRAm8a@minute \
    --to=ink@unseen.parts \
    --cc=arnd@arndb.de \
    --cc=ebiederm@xmission.com \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=kees@kernel.org \
    --cc=kernel@mkarcher.dialup.fu-berlin.de \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=loongarch@lists.linux.dev \
    --cc=macro@orcam.me.uk \
    --cc=mattst88@gmail.com \
    --cc=mcree@orcon.net.nz \
    --cc=paulmck@kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=sam@gentoo.org \
    --cc=util-linux@vger.kernel.org \
    --cc=zeha@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.