* Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
From: John Paul Adrian Glaubitz @ 2025-01-11 10:37 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Arnd Bergmann, Richard Henderson, Matt Turner, Kees Cook,
Paul E. McKenney, linux-alpha, linux-mm, linux-kernel,
Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org>
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
^ permalink raw reply
* Re: [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
From: Richard Henderson @ 2025-01-11 1:17 UTC (permalink / raw)
To: Eric W. Biederman, John Paul Adrian Glaubitz
Cc: Arnd Bergmann, Matt Turner, Kees Cook, Paul E. McKenney,
linux-alpha, linux-mm, linux-kernel, Michael Cree, Sam James,
Maciej W. Rozycki, Geert Uytterhoeven, Michael Karcher,
Chris Hofstaedtler, util-linux, linux-mips, loongarch
In-Reply-To: <87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org>
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;
^ permalink raw reply
* [PATCH] alpha/elf: Fix misc/setarch test of util-linux by removing 32bit support
From: Eric W. Biederman @ 2025-01-11 0:16 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Arnd Bergmann, Richard Henderson, Matt Turner, Kees Cook,
Paul E. McKenney, linux-alpha, linux-mm, linux-kernel,
Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <cc420e1a843da3cf349607369851c338f4049c4e.camel@physik.fu-berlin.de>
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
^ permalink raw reply related
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Arnd Bergmann @ 2025-01-09 20:53 UTC (permalink / raw)
To: Maciej W. Rozycki, Eric W. Biederman
Cc: John Paul Adrian Glaubitz, Richard Henderson, Matt Turner,
Kees Cook, Paul E. McKenney, linux-alpha, linux-mm, linux-kernel,
Michael Cree, Sam James, Geert Uytterhoeven, Michael Karcher,
Chris Hofstaedtler, util-linux, linux-mips, loongarch
In-Reply-To: <alpine.DEB.2.21.2501091953050.18889@angie.orcam.me.uk>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Maciej W. Rozycki @ 2025-01-09 20:10 UTC (permalink / raw)
To: Eric W. Biederman
Cc: John Paul Adrian Glaubitz, Arnd Bergmann, Richard Henderson,
Matt Turner, Kees Cook, Paul E. McKenney, linux-alpha, linux-mm,
linux-kernel, Michael Cree, Sam James, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <87ed1cufj1.fsf@email.froward.int.ebiederm.org>
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
^ permalink raw reply
* Re: [ANNOUNCE] util-linux v2.40.3
From: Karel Zak @ 2025-01-09 19:32 UTC (permalink / raw)
To: Chris Hofstaedtler; +Cc: util-linux
In-Reply-To: <wzdbgtxffvujwnv5oeeutbmeodm5chcmelyhwhhx7yt6dym7lh@j5vdmg3rnm3z>
On Thu, Jan 09, 2025 at 02:21:06PM GMT, Chris Hofstaedtler wrote:
> Hi Karel,
>
> * Karel Zak <kzak@redhat.com> [250109 13:54]:
> > The util-linux stable maintenance release v2.40.3 is now available at
> >
> > http://www.kernel.org/pub/linux/utils/util-linux/v2.40/
>
> I'm not sure where this comes from, but building the translated
> manpages seems to fail:
>
> GEN ro : fsck.minix.8
> asciidoctor: ERROR: fsck.minix.8.adoc: line 29: dropping cells from incomplete row detected end of table
>
> I haven't dug deeper yet; if someone has an idea upfront that'd be
> great.
https://github.com/util-linux/util-linux/pull/3346
However, I forgot to merge it to the stable branch as well.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Eric W. Biederman @ 2025-01-09 16:18 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Arnd Bergmann, Richard Henderson, Matt Turner, Kees Cook,
Paul E. McKenney, linux-alpha, linux-mm, linux-kernel,
Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <cc420e1a843da3cf349607369851c338f4049c4e.camel@physik.fu-berlin.de>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Eric W. Biederman @ 2025-01-09 17:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: John Paul Adrian Glaubitz, Richard Henderson, Matt Turner,
Kees Cook, Paul E. McKenney, linux-alpha, linux-mm, linux-kernel,
Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <9b1749f0-e936-4bf5-90d6-8cf15e4f0ed9@app.fastmail.com>
"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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Arnd Bergmann @ 2025-01-09 16:52 UTC (permalink / raw)
To: Eric W. Biederman, John Paul Adrian Glaubitz
Cc: Richard Henderson, Matt Turner, Kees Cook, Paul E. McKenney,
linux-alpha, linux-mm, linux-kernel, Michael Cree, Sam James,
Maciej W. Rozycki, Geert Uytterhoeven, Michael Karcher,
Chris Hofstaedtler, util-linux, linux-mips, loongarch
In-Reply-To: <87ed1cufj1.fsf@email.froward.int.ebiederm.org>
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
^ permalink raw reply
* Re: [ANNOUNCE] util-linux v2.40.3
From: Chris Hofstaedtler @ 2025-01-09 13:21 UTC (permalink / raw)
To: Karel Zak; +Cc: linux-kernel, linux-fsdevel, util-linux
In-Reply-To: <xw6eivqjw6nc75sbejmi3nkbfssmakkrwpbjpfqtwwbpqxmb4f@rmyrm5gnizln>
Hi Karel,
* Karel Zak <kzak@redhat.com> [250109 13:54]:
> The util-linux stable maintenance release v2.40.3 is now available at
>
> http://www.kernel.org/pub/linux/utils/util-linux/v2.40/
I'm not sure where this comes from, but building the translated
manpages seems to fail:
GEN ro : fsck.minix.8
asciidoctor: ERROR: fsck.minix.8.adoc: line 29: dropping cells from incomplete row detected end of table
I haven't dug deeper yet; if someone has an idea upfront that'd be
great.
Thanks,
Chris
^ permalink raw reply
* [ANNOUNCE] util-linux v2.40.3
From: Karel Zak @ 2025-01-09 12:53 UTC (permalink / raw)
To: linux-kernel, linux-fsdevel, util-linux
The util-linux stable maintenance release v2.40.3 is now available at
http://www.kernel.org/pub/linux/utils/util-linux/v2.40/
Feedback and bug reports, as always, are welcomed.
Karel
util-linux v2.40.3 Release Notes
================================
Changes between v2.40.2 and v2.40.3
-----------------------------------
agetty:
- Prevent cursor escape [Stanislav Brabec]
- add "systemd" to --version output [Karel Zak]
- fix ambiguous ‘else’ [-Werror=dangling-else] [Karel Zak]
audit-arch.h:
- add defines for m68k, sh [Chris Hofstaedtler]
autotools:
- Check for BPF_OBJ_NAME_LEN (required by lsfd) [Karel Zak]
- add --disable-enosys, check for linux/audit.h [Karel Zak]
- add Libs.private to uuid.pc [Karel Zak]
- allow enabling dmesg with --disable-all-programs [Henrik Lindström]
- allow enabling lsblk with --disable-all-programs [Henrik Lindström]
- check for sys/vfs.h and linux/bpf.h [Karel Zak]
- fix securedir and pam_lastlog2 install [Karel Zak]
bash-completion:
- add `--pty` and `--no-pty` options for `su` and `runuser` [Christoph Anton Mitterer]
- complete `--user` only for `runuser`, not for `su` [Christoph Anton Mitterer]
chcpu(8):
- Document CPU deconfiguring behavior [Mete Durlu]
- Fix typo [Mete Durlu]
ci:
- bump coveralls compiler version to gcc 13 [Karel Zak]
doc:
- fsck.8.adoc - fix email typo [Geoffrey Casper]
docs:
- update AUTHORS file [Karel Zak]
fdisk:
- (man) improve --sector-size description [Karel Zak]
- fix SGI boot file prompt [mr-bronson]
- fix fdisk_sgi_set_bootfile return value [mr-bronson]
- fix sgi_check_bootfile name size minimum [mr-bronson]
- fix sgi_menu_cb return value [mr-bronson]
fincore:
- Use correct syscall number for cachestat on alpha [John Paul Adrian Glaubitz]
fstab.5 mount:
- fstab.5 mount.8 add note about field separator [Karel Zak]
hardlink:
- fix memory corruption (size calculation) [Karel Zak]
- hardlink.1 directory|file is mandatory [наб]
hwclock:
- Remove ioperm declare as it causes nested extern declare warning [Zhaoming Luo]
lib/env:
- fix env_list_setenv() for strings without '=' [Karel Zak]
libblkid:
- (exfat) validate fields used by prober [Thomas Weißschuh]
- (gpt) use blkid_probe_verify_csum() for partition array checksum [Thomas Weißschuh]
- add FSLASTBLOCK for swaparea [Karel Zak]
- bitlocker add image for Windows 7+ BitLocker [Victor Westerhuis]
- bitlocker fix version on big-endian systems [Victor Westerhuis]
- improve portability [Yang Kun]
libfdisk:
- make sure libblkid uses the same sector size [Karel Zak]
libmount:
- exec mount helpers with posixly correct argument order [nilfsuser5678]
- extract common error handling function [John Keeping]
- propagate first error of multiple filesystem types [John Keeping]
libmount/context_mount:
- fix argument number comments [nilfsuser5678]
logger:
- correctly format tv_usec [Thomas Weißschuh]
lscpu:
- Skip aarch64 decode path for rest of the architectures [Pratik R. Sampat]
- make code more readable [Karel Zak]
lslocks:
- remove deadcode [coverity scan] [Karel Zak]
lsns:
- ignore ESRCH errors reported when accessing files under /proc [Masatake YAMATO]
man pages:
- document `--user` option for `runuser` [Christoph Anton Mitterer]
- use `user` rather than `username` [Christoph Anton Mitterer]
meson:
- check for BPF_OBJ_NAME_LEN and linux/bpf.h [Karel Zak]
mkswap:
- set selinux label also when creating file [Zbigniew Jędrzejewski-Szmek]
more:
- make sure we have data on stderr [Karel Zak]
nsenter:
- support empty environ[] [Karel Zak]
partx:
- Fix example in man page [Michal Suchanek]
po:
- merge changes [Karel Zak]
- update de.po (from translationproject.org) [Mario Blättermann]
- update ja.po (from translationproject.org) [Hideki Yoshida]
- update pt_BR.po (from translationproject.org) [Rafael Fontenelle]
- update sr.po (from translationproject.org) [Мирослав Николић]
- update zh_CN.po (from translationproject.org) [Mingye Wang (Artoria2e5)]
po-man:
- add missing langs to po4a.cfg [Karel Zak]
- fix typo, update .gitignore [Karel Zak]
- merge changes [Karel Zak]
- update fr.po (from translationproject.org) [Frédéric Marchal]
- update pt_BR.po (from translationproject.org) [Rafael Fontenelle]
tests:
- fdisk/bsd Update expected output for alpha [John Paul Adrian Glaubitz]
umount, losetup:
- Document loop destroy behavior [Stanislav Brabec]
uuidd:
- fix /var/lib/libuuid mode uuidd-tmpfiles.conf [Karel Zak]
- fix typo in tmpfiles.conf [Karel Zak]
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: John Paul Adrian Glaubitz @ 2025-01-09 9:12 UTC (permalink / raw)
To: Arnd Bergmann, Richard Henderson, Matt Turner, Eric W. Biederman,
Kees Cook, Paul E. McKenney, linux-alpha, linux-mm, linux-kernel
Cc: Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <82d33a2d-dffe-4268-a175-4536b3f9c07f@app.fastmail.com>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Arnd Bergmann @ 2025-01-09 8:56 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Richard Henderson, Matt Turner,
Eric W. Biederman, Kees Cook, Paul E. McKenney, linux-alpha,
linux-mm, linux-kernel
Cc: Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <bff3cfad8a87799101891b4f786c5104db9dab13.camel@physik.fu-berlin.de>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: John Paul Adrian Glaubitz @ 2025-01-09 8:46 UTC (permalink / raw)
To: Arnd Bergmann, Richard Henderson, Matt Turner, Eric W. Biederman,
Kees Cook, Paul E. McKenney, linux-alpha, linux-mm, linux-kernel
Cc: Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <678ee681-12c3-4e79-a04b-495daf343846@app.fastmail.com>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Arnd Bergmann @ 2025-01-09 8:43 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Richard Henderson, Matt Turner,
Eric W. Biederman, Kees Cook, Paul E. McKenney, linux-alpha,
linux-mm, linux-kernel
Cc: Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux, linux-mips,
loongarch
In-Reply-To: <24f03227-1b55-4e50-b6e9-7ac74fda2602@app.fastmail.com>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Arnd Bergmann @ 2025-01-09 8:01 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Richard Henderson, Matt Turner,
Eric W. Biederman, Kees Cook, Paul E. McKenney, linux-alpha,
linux-mm, linux-kernel
Cc: Michael Cree, Sam James, Maciej W. Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux
In-Reply-To: <20250103140148.370368-1-glaubitz@physik.fu-berlin.de>
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
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Jeff Xu @ 2025-01-09 0:52 UTC (permalink / raw)
To: Kees Cook
Cc: John Paul Adrian Glaubitz, Richard Henderson, Matt Turner,
Jeff Xu, Eric Biederman, Arnd Bergmann, Paul E. McKenney,
linux-alpha, linux-mm, linux-kernel, Michael Cree, Sam James,
Maciej W . Rozycki, Geert Uytterhoeven, Michael Karcher,
Chris Hofstaedtler, util-linux
In-Reply-To: <202501081442.AB725C7D0@keescook>
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
>
^ permalink raw reply
* Re: [PATCH] alpha: Fix personality flag propagation across an exec
From: Kees Cook @ 2025-01-08 22:49 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Richard Henderson, Matt Turner, Jeff Xu, Eric Biederman,
Arnd Bergmann, Paul E. McKenney, linux-alpha, linux-mm,
linux-kernel, Michael Cree, Sam James, Maciej W . Rozycki,
Geert Uytterhoeven, Michael Karcher, Chris Hofstaedtler,
util-linux
In-Reply-To: <20250103140148.370368-1-glaubitz@physik.fu-berlin.de>
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
^ permalink raw reply
* Re: v2.40.3 plan
From: Karel Zak @ 2025-01-06 17:31 UTC (permalink / raw)
To: John Paul Adrian Glaubitz; +Cc: Stanislav Brabec, util-linux
In-Reply-To: <aa437ab7756dad03aa6b6d774acfd82e67bdbdb2.camel@physik.fu-berlin.de>
On Mon, Jan 06, 2025 at 04:02:28PM GMT, John Paul Adrian Glaubitz wrote:
> Hi Karel,
>
> On Mon, 2025-01-06 at 15:58 +0100, Karel Zak wrote:
> > Looks good, all three have been backported to the v2.40 branch.
>
> Could you also backport these two which fix testsuite issues on alpha?
>
> commit a0ce085c261a1d981bfa0acd4272b6ba77bfa3be
> Author: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Date: Wed Dec 25 16:21:13 2024 +0100
>
> fincore: Use correct syscall number for cachestat on alpha
>
> Fixes #3331, #3333
>
> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>
> commit 851a168e82a1264e2693acba5746ec30eee0c43b
> Author: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Date: Wed Dec 25 14:08:32 2024 +0100
>
> tests: fdisk/bsd: Update expected output for alpha
>
> Fixes #3332
>
> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Both have already been merged :)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: v2.40.3 plan
From: John Paul Adrian Glaubitz @ 2025-01-06 15:02 UTC (permalink / raw)
To: Karel Zak, Stanislav Brabec; +Cc: util-linux
In-Reply-To: <ewc6glghupyk4koka764ymyjzuedczl4uknucujc6vlj3ohgpb@rw5jgn5dxzqe>
Hi Karel,
On Mon, 2025-01-06 at 15:58 +0100, Karel Zak wrote:
> Looks good, all three have been backported to the v2.40 branch.
Could you also backport these two which fix testsuite issues on alpha?
commit a0ce085c261a1d981bfa0acd4272b6ba77bfa3be
Author: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed Dec 25 16:21:13 2024 +0100
fincore: Use correct syscall number for cachestat on alpha
Fixes #3331, #3333
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
commit 851a168e82a1264e2693acba5746ec30eee0c43b
Author: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed Dec 25 14:08:32 2024 +0100
tests: fdisk/bsd: Update expected output for alpha
Fixes #3332
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: v2.40.3 plan
From: Karel Zak @ 2025-01-06 14:58 UTC (permalink / raw)
To: Stanislav Brabec; +Cc: util-linux
In-Reply-To: <e0544e22-d8a3-4e13-908b-97a07cbff40b@suse.cz>
On Sat, Jan 04, 2025 at 05:27:05PM GMT, Stanislav Brabec wrote:
> These would be nice iin 2.40 branch:
>
> Merge branch 'PR/libmount-vfs-ro' that makes mountfd usable in most cases
> (but still not fully compatible):
> 4095c5bb6757b506acbe47a8bc60d8ebd04ba8a5
> libmount: implement ro[=vfs,fs]
> and
> 03b2e73ae649a957a4f695df4f44c2cbce8d5f92
> libmount: improving readability
Yes, I understand, but in my opinion, it's too intrusive for the .3
release. I would prefer to only have minor changes and actual bug
fixes, rather than new features.
> 20b405c0fea29675e1fb54b894eb1c18459f9d50
> agetty: Prevent cursor escape
> Cosmetic fix, but visible.
>
> 50a3efab6d126b28fcdcc28f1a0cd5cd596ae357
> lscpu: Skip aarch64 decode path for rest of the architectures
> Ensures proper lscpu behavior.
>
> fc67f18be51f57ee9a59a0f8f7ad16f284a24a3e
> umount, losetup: Document loop destroy behavior
> Just a doc update that explains unexpected behavior.
Looks good, all three have been backported to the v2.40 branch.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: v2.40.3 plan
From: Stanislav Brabec @ 2025-01-04 16:28 UTC (permalink / raw)
To: Karel Zak, util-linux
In-Reply-To: <4wnkdjqtwlx5pjeknj7wqmk5bgftoyzpqijqguekcepcdyrgmn@pofpabk4awvg>
Karel Zak wrote:
> If there is anything missing or if you would like to add something to
> the release, please let me know.
These would be nice iin 2.40 branch:
Merge branch 'PR/libmount-vfs-ro' that makes mountfd usable in most
cases (but still not fully compatible):
4095c5bb6757b506acbe47a8bc60d8ebd04ba8a5
libmount: implement ro[=vfs,fs]
and
03b2e73ae649a957a4f695df4f44c2cbce8d5f92
libmount: improving readability
20b405c0fea29675e1fb54b894eb1c18459f9d50
agetty: Prevent cursor escape
Cosmetic fix, but visible.
50a3efab6d126b28fcdcc28f1a0cd5cd596ae357
lscpu: Skip aarch64 decode path for rest of the architectures
Ensures proper lscpu behavior.
fc67f18be51f57ee9a59a0f8f7ad16f284a24a3e
umount, losetup: Document loop destroy behavior
Just a doc update that explains unexpected behavior.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com
Křižíkova 148/34 (Corso IIa) tel: +420 284 084 060
186 00 Praha 8-Karlín fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
^ permalink raw reply
* [PATCH] alpha: Fix personality flag propagation across an exec
From: John Paul Adrian Glaubitz @ 2025-01-03 14:01 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Eric Biederman, Kees Cook,
Arnd Bergmann, John Paul Adrian Glaubitz, Paul E. McKenney,
linux-alpha, linux-mm, linux-kernel
Cc: Michael Cree, Sam James, Maciej W . Rozycki, Geert Uytterhoeven,
Michael Karcher, Chris Hofstaedtler, util-linux
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
^ permalink raw reply related
* Re: is it possible to add a new filter to detect unusable partition types
From: Zdenek Kabelac @ 2024-12-19 10:50 UTC (permalink / raw)
To: Thomas Weißschuh, Karel Zak, Glass Su, Heming Zhao,
linux-lvm@lists.linux.dev, grub-devel, util-linux
In-Reply-To: <jcqrtifxjk2adtngyykvyoffh6ab3twulqra4ugq7satddqob7__49168.7655843393$1734583719$gmane$org@rngyhl7nuyhk>
Dne 19. 12. 24 v 5:48 Michael Chang napsal(a):
> On Wed, Dec 18, 2024 at 06:05:54PM +0100, Thomas Weißschuh wrote:
>> On 2024-12-18 15:44:45+0100, Karel Zak wrote:
>>> On Wed, Dec 18, 2024 at 11:12:59AM GMT, Zdenek Kabelac wrote:
>>
>> [..]
>>
>>>> And in the same way blkid should expose installed grub loader - currently
>>>> the partition with installed grub looks 'empty' with blkid....
>>>
>>> The issue I see is that boot loaders can coexist with filesystems on
>>> the same device. This can lead to unexpected warnings when attempting
>>> to view the contents of the device using mkfs tools.
>>
>> Isn't this specifically about the grub second stage on GPT systems
>> inside a dedicated partition?
>
> Yes, GPT has no unallocated space similar to the MBR gap in the MSDOS
> partition table that can be repurposed for grub second stage, therefore
> a dedicated partition has to be defined and allocated. A similar scheme
> is also used in PowerPC, where a dedicated firmware PReP boot partition
> must be allocated for the boot code.
Hi
Yep - it's obvious grub needs to have a space to store its data.
In fact if a device would be 'just & only' a PV, such a PV actually has
prepared empty space to be consumed by grub - (see 'pvcreate
--bootloaderareasize) - which probably never reached its audience - so when
the user is using PV lvm2 he should not need a special dedicated partition
(theoretically).
But all that is said here is that choosing some 'random' GUID GPT partition
type really doesn't change anything in Linux - all tools in Linux are scanning
content of device - checking for 'partition type' is highly unusual and
pretty much undefined.
So the focus should go to blkid being able to report that device is occupied
by some content.
>
>> There should be no valid coexistence with a filesystem.
>>
>> So having a probe in blkid looks reasonable to me.
Speaking of this - there was use in old ages (and I believe it's still support
by lvm2) the usage of a PV & MBR at the same time (it's also the reason why
the PV header is storing it's LABELONE on 2nd. sector (512b)
This has also caused some troubles in past to properly identify device content.
Also blkid already can identify multiple signatures on the same device so it's
just about the priority which one will be then shown by 'udev' as primary.
lvm2 also checks and clears all signatures one-by-one...
>>
>> Not that it helps in the specific case mentioned above, where everybody
>> is using --force anyways.
>
> That's the reason I think adding such a check in grub-install doesn't
> help at all. After adding the check, I believe the tools managing the
> bootloader installation will start to use wipefs or enforce --force to
> grub-install to make sure no leftover can get in the way. In that sense,
> it seems like unnecessary breaking change to the toolings.
I guess we may not move forward with this logic...
(aka it's ok change lvm2 to not wipe, but it's fine grub will overwrite anything)
lvm2 is for long time trying to advocate against using '--force' regularly.
In some cases we've introduced even 2nd. --force required to be entered if the
compatibility usage would be broken otherwise.
Thus the proper logic should be that some 'operations' that currently do need
--force - may have it's own dedicated option - i.e. in my case grub usually
doesn't really like to store it's data on the partition in use - so maybe
there can be an option just for this aka --in-use-is-ok y|n
Similarly lvm2 has 'pvcreate --zero y' to clear device content
unconditionally - so there is no need to use --force for such case - although
it takes time to teach other tools to use options the right way....
Regard
Zdenek
^ permalink raw reply
* Re: is it possible to add a new filter to detect unusable partition types
From: Michael Chang @ 2024-12-19 4:48 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Karel Zak, Zdenek Kabelac, Glass Su, Heming Zhao,
linux-lvm@lists.linux.dev, grub-devel, util-linux
In-Reply-To: <860960db-bb66-453c-a392-1495690bb2ff@t-8ch.de>
On Wed, Dec 18, 2024 at 06:05:54PM +0100, Thomas Weißschuh wrote:
> On 2024-12-18 15:44:45+0100, Karel Zak wrote:
> > On Wed, Dec 18, 2024 at 11:12:59AM GMT, Zdenek Kabelac wrote:
>
> [..]
>
> > > And in the same way blkid should expose installed grub loader - currently
> > > the partition with installed grub looks 'empty' with blkid....
> >
> > The issue I see is that boot loaders can coexist with filesystems on
> > the same device. This can lead to unexpected warnings when attempting
> > to view the contents of the device using mkfs tools.
>
> Isn't this specifically about the grub second stage on GPT systems
> inside a dedicated partition?
Yes, GPT has no unallocated space similar to the MBR gap in the MSDOS
partition table that can be repurposed for grub second stage, therefore
a dedicated partition has to be defined and allocated. A similar scheme
is also used in PowerPC, where a dedicated firmware PReP boot partition
must be allocated for the boot code.
See Also:
https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation
> There should be no valid coexistence with a filesystem.
>
> So having a probe in blkid looks reasonable to me.
>
> Not that it helps in the specific case mentioned above, where everybody
> is using --force anyways.
That's the reason I think adding such a check in grub-install doesn't
help at all. After adding the check, I believe the tools managing the
bootloader installation will start to use wipefs or enforce --force to
grub-install to make sure no leftover can get in the way. In that sense,
it seems like unnecessary breaking change to the toolings.
Thanks,
Michael
>
>
> Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox