FAILED: patch "[PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h" failed to apply to 6.10-stable tree

FAILED: patch "[PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h" failed to apply to 6.10-stable tree

[gregkh]

The patch below does not apply to the 6.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.10.y
git checkout FETCH_HEAD
git cherry-pick -x 7697a0fe0154468f5df35c23ebd7aa48994c2cdc
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024072921-props-yam-bb2b@gregkh' --subject-prefix 'PATCH 6.10.y' HEAD^..

Possible dependencies:

7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h")
26a3b85bac08 ("loongarch: convert to generic syscall table")
505d66d1abfb ("clone3: drop __ARCH_WANT_SYS_CLONE3 macro")

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 7697a0fe0154468f5df35c23ebd7aa48994c2cdc Mon Sep 17 00:00:00 2001
From: Huacai Chen <chenhuacai@kernel.org>
Date: Sat, 20 Jul 2024 22:40:58 +0800
Subject: [PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

Chromium sandbox apparently wants to deny statx [1] so it could properly
inspect arguments after the sandboxed process later falls back to fstat.
Because there's currently not a "fd-only" version of statx, so that the
sandbox has no way to ensure the path argument is empty without being
able to peek into the sandboxed process's memory. For architectures able
to do newfstatat though, glibc falls back to newfstatat after getting
-ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
inspecting the path argument, transforming allowed newfstatat's into
fstat instead which is allowed and has the same type of return value.

But, as LoongArch is the first architecture to not have fstat nor
newfstatat, the LoongArch glibc does not attempt falling back at all
when it gets -ENOSYS for statx -- and you see the problem there!

Actually, back when the LoongArch port was under review, people were
aware of the same problem with sandboxing clone3 [3], so clone was
eventually kept. Unfortunately it seemed at that time no one had noticed
statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
postponing the problem further), it seems inevitable that we would need
to tackle seccomp deep argument inspection.

However, this is obviously a decision that shouldn't be taken lightly,
so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
in unistd.h. This is the simplest solution for now, and so we hope the
community will tackle the long-standing problem of seccomp deep argument
inspection in the future [4][5].

Also add "newstat" to syscall_abis_64 in Makefile.syscalls due to
upstream asm-generic changes.

More infomation please reading this thread [6].

[1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
[2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
[3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
[4] https://lwn.net/Articles/799557/
[5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
[6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t

Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

diff --git a/arch/loongarch/include/asm/unistd.h b/arch/loongarch/include/asm/unistd.h
index fc0a481a7416..e2c0f3d86c7b 100644
--- a/arch/loongarch/include/asm/unistd.h
+++ b/arch/loongarch/include/asm/unistd.h
@@ -8,6 +8,7 @@
 
 #include <uapi/asm/unistd.h>
 
+#define __ARCH_WANT_NEW_STAT
 #define __ARCH_WANT_SYS_CLONE
 
 #define NR_syscalls (__NR_syscalls)
diff --git a/arch/loongarch/kernel/Makefile.syscalls b/arch/loongarch/kernel/Makefile.syscalls
index ab7d9baa2915..523bb411a3bc 100644
--- a/arch/loongarch/kernel/Makefile.syscalls
+++ b/arch/loongarch/kernel/Makefile.syscalls
@@ -1,4 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 
-# No special ABIs on loongarch so far
-syscall_abis_64 +=
+syscall_abis_64 += newstat

Re: FAILED: patch "[PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h" failed to apply to 6.10-stable tree

[Huacai Chen]

Hi, Greg,

For stable kernels before 6.11 please use this patch, thanks.

https://lore.kernel.org/loongarch/20240511100157.2334539-1-chenhuacai@loongson.cn/

Huacai

On Mon, Jul 29, 2024 at 8:15 PM <gregkh@linuxfoundation.org> wrote:
>
>
> The patch below does not apply to the 6.10-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
>
> To reproduce the conflict and resubmit, you may use the following commands:
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.10.y
> git checkout FETCH_HEAD
> git cherry-pick -x 7697a0fe0154468f5df35c23ebd7aa48994c2cdc
> # <resolve conflicts, build, test, etc.>
> git commit -s
> git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2024072921-props-yam-bb2b@gregkh' --subject-prefix 'PATCH 6.10.y' HEAD^..
>
> Possible dependencies:
>
> 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h")
> 26a3b85bac08 ("loongarch: convert to generic syscall table")
> 505d66d1abfb ("clone3: drop __ARCH_WANT_SYS_CLONE3 macro")
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> From 7697a0fe0154468f5df35c23ebd7aa48994c2cdc Mon Sep 17 00:00:00 2001
> From: Huacai Chen <chenhuacai@kernel.org>
> Date: Sat, 20 Jul 2024 22:40:58 +0800
> Subject: [PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h
>
> Chromium sandbox apparently wants to deny statx [1] so it could properly
> inspect arguments after the sandboxed process later falls back to fstat.
> Because there's currently not a "fd-only" version of statx, so that the
> sandbox has no way to ensure the path argument is empty without being
> able to peek into the sandboxed process's memory. For architectures able
> to do newfstatat though, glibc falls back to newfstatat after getting
> -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> inspecting the path argument, transforming allowed newfstatat's into
> fstat instead which is allowed and has the same type of return value.
>
> But, as LoongArch is the first architecture to not have fstat nor
> newfstatat, the LoongArch glibc does not attempt falling back at all
> when it gets -ENOSYS for statx -- and you see the problem there!
>
> Actually, back when the LoongArch port was under review, people were
> aware of the same problem with sandboxing clone3 [3], so clone was
> eventually kept. Unfortunately it seemed at that time no one had noticed
> statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> postponing the problem further), it seems inevitable that we would need
> to tackle seccomp deep argument inspection.
>
> However, this is obviously a decision that shouldn't be taken lightly,
> so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> in unistd.h. This is the simplest solution for now, and so we hope the
> community will tackle the long-standing problem of seccomp deep argument
> inspection in the future [4][5].
>
> Also add "newstat" to syscall_abis_64 in Makefile.syscalls due to
> upstream asm-generic changes.
>
> More infomation please reading this thread [6].
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> [4] https://lwn.net/Articles/799557/
> [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
>
> diff --git a/arch/loongarch/include/asm/unistd.h b/arch/loongarch/include/asm/unistd.h
> index fc0a481a7416..e2c0f3d86c7b 100644
> --- a/arch/loongarch/include/asm/unistd.h
> +++ b/arch/loongarch/include/asm/unistd.h
> @@ -8,6 +8,7 @@
>
>  #include <uapi/asm/unistd.h>
>
> +#define __ARCH_WANT_NEW_STAT
>  #define __ARCH_WANT_SYS_CLONE
>
>  #define NR_syscalls (__NR_syscalls)
> diff --git a/arch/loongarch/kernel/Makefile.syscalls b/arch/loongarch/kernel/Makefile.syscalls
> index ab7d9baa2915..523bb411a3bc 100644
> --- a/arch/loongarch/kernel/Makefile.syscalls
> +++ b/arch/loongarch/kernel/Makefile.syscalls
> @@ -1,4 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> -# No special ABIs on loongarch so far
> -syscall_abis_64 +=
> +syscall_abis_64 += newstat
>

Re: FAILED: patch "[PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h" failed to apply to 6.10-stable tree

[Greg KH]

On Mon, Jul 29, 2024 at 10:36:28PM +0800, Huacai Chen wrote:
> Hi, Greg,
> 
> For stable kernels before 6.11 please use this patch, thanks.
> 
> https://lore.kernel.org/loongarch/20240511100157.2334539-1-chenhuacai@loongson.cn/

Please submit it here in a format we can apply it in.

thanks,

greg k-h

[PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

[Huacai Chen]

Chromium sandbox apparently wants to deny statx [1] so it could properly
inspect arguments after the sandboxed process later falls back to fstat.
Because there's currently not a "fd-only" version of statx, so that the
sandbox has no way to ensure the path argument is empty without being
able to peek into the sandboxed process's memory. For architectures able
to do newfstatat though, glibc falls back to newfstatat after getting
-ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
inspecting the path argument, transforming allowed newfstatat's into
fstat instead which is allowed and has the same type of return value.

But, as LoongArch is the first architecture to not have fstat nor
newfstatat, the LoongArch glibc does not attempt falling back at all
when it gets -ENOSYS for statx -- and you see the problem there!

Actually, back when the LoongArch port was under review, people were
aware of the same problem with sandboxing clone3 [3], so clone was
eventually kept. Unfortunately it seemed at that time no one had noticed
statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
postponing the problem further), it seems inevitable that we would need
to tackle seccomp deep argument inspection.

However, this is obviously a decision that shouldn't be taken lightly,
so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
in unistd.h. This is the simplest solution for now, and so we hope the
community will tackle the long-standing problem of seccomp deep argument
inspection in the future [4][5].

More infomation please reading this thread [6].

[1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
[2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
[3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
[4] https://lwn.net/Articles/799557/
[5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
[6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t

Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
 arch/loongarch/include/uapi/asm/unistd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
index fcb668984f03..b344b1f91715 100644
--- a/arch/loongarch/include/uapi/asm/unistd.h
+++ b/arch/loongarch/include/uapi/asm/unistd.h
@@ -1,4 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#define __ARCH_WANT_NEW_STAT
 #define __ARCH_WANT_SYS_CLONE
 #define __ARCH_WANT_SYS_CLONE3
 
-- 
2.43.5

Re: [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

[Greg Kroah-Hartman]

On Tue, Jul 30, 2024 at 10:25:42AM +0800, Huacai Chen wrote:
> Chromium sandbox apparently wants to deny statx [1] so it could properly
> inspect arguments after the sandboxed process later falls back to fstat.
> Because there's currently not a "fd-only" version of statx, so that the
> sandbox has no way to ensure the path argument is empty without being
> able to peek into the sandboxed process's memory. For architectures able
> to do newfstatat though, glibc falls back to newfstatat after getting
> -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> inspecting the path argument, transforming allowed newfstatat's into
> fstat instead which is allowed and has the same type of return value.
> 
> But, as LoongArch is the first architecture to not have fstat nor
> newfstatat, the LoongArch glibc does not attempt falling back at all
> when it gets -ENOSYS for statx -- and you see the problem there!
> 
> Actually, back when the LoongArch port was under review, people were
> aware of the same problem with sandboxing clone3 [3], so clone was
> eventually kept. Unfortunately it seemed at that time no one had noticed
> statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> postponing the problem further), it seems inevitable that we would need
> to tackle seccomp deep argument inspection.
> 
> However, this is obviously a decision that shouldn't be taken lightly,
> so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> in unistd.h. This is the simplest solution for now, and so we hope the
> community will tackle the long-standing problem of seccomp deep argument
> inspection in the future [4][5].
> 
> More infomation please reading this thread [6].
> 
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> [4] https://lwn.net/Articles/799557/
> [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
>  arch/loongarch/include/uapi/asm/unistd.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
> index fcb668984f03..b344b1f91715 100644
> --- a/arch/loongarch/include/uapi/asm/unistd.h
> +++ b/arch/loongarch/include/uapi/asm/unistd.h
> @@ -1,4 +1,5 @@
>  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#define __ARCH_WANT_NEW_STAT
>  #define __ARCH_WANT_SYS_CLONE
>  #define __ARCH_WANT_SYS_CLONE3
>  
> -- 
> 2.43.5
> 
> 

What kernel branch(s) is this for?

thanks,

greg k-h

Re: [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

[Huacai Chen]

On Tue, Jul 30, 2024 at 10:24 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Jul 30, 2024 at 10:25:42AM +0800, Huacai Chen wrote:
> > Chromium sandbox apparently wants to deny statx [1] so it could properly
> > inspect arguments after the sandboxed process later falls back to fstat.
> > Because there's currently not a "fd-only" version of statx, so that the
> > sandbox has no way to ensure the path argument is empty without being
> > able to peek into the sandboxed process's memory. For architectures able
> > to do newfstatat though, glibc falls back to newfstatat after getting
> > -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> > inspecting the path argument, transforming allowed newfstatat's into
> > fstat instead which is allowed and has the same type of return value.
> >
> > But, as LoongArch is the first architecture to not have fstat nor
> > newfstatat, the LoongArch glibc does not attempt falling back at all
> > when it gets -ENOSYS for statx -- and you see the problem there!
> >
> > Actually, back when the LoongArch port was under review, people were
> > aware of the same problem with sandboxing clone3 [3], so clone was
> > eventually kept. Unfortunately it seemed at that time no one had noticed
> > statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> > postponing the problem further), it seems inevitable that we would need
> > to tackle seccomp deep argument inspection.
> >
> > However, this is obviously a decision that shouldn't be taken lightly,
> > so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> > in unistd.h. This is the simplest solution for now, and so we hope the
> > community will tackle the long-standing problem of seccomp deep argument
> > inspection in the future [4][5].
> >
> > More infomation please reading this thread [6].
> >
> > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> > [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> > [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> > [4] https://lwn.net/Articles/799557/
> > [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> > [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > ---
> >  arch/loongarch/include/uapi/asm/unistd.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
> > index fcb668984f03..b344b1f91715 100644
> > --- a/arch/loongarch/include/uapi/asm/unistd.h
> > +++ b/arch/loongarch/include/uapi/asm/unistd.h
> > @@ -1,4 +1,5 @@
> >  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > +#define __ARCH_WANT_NEW_STAT
> >  #define __ARCH_WANT_SYS_CLONE
> >  #define __ARCH_WANT_SYS_CLONE3
> >
> > --
> > 2.43.5
> >
> >
>
> What kernel branch(s) is this for?
For 6.1~6.10.

Huacai
>
> thanks,
>
> greg k-h

Re: [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

[Greg Kroah-Hartman]

On Wed, Jul 31, 2024 at 09:06:56AM +0800, Huacai Chen wrote:
> On Tue, Jul 30, 2024 at 10:24 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jul 30, 2024 at 10:25:42AM +0800, Huacai Chen wrote:
> > > Chromium sandbox apparently wants to deny statx [1] so it could properly
> > > inspect arguments after the sandboxed process later falls back to fstat.
> > > Because there's currently not a "fd-only" version of statx, so that the
> > > sandbox has no way to ensure the path argument is empty without being
> > > able to peek into the sandboxed process's memory. For architectures able
> > > to do newfstatat though, glibc falls back to newfstatat after getting
> > > -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> > > inspecting the path argument, transforming allowed newfstatat's into
> > > fstat instead which is allowed and has the same type of return value.
> > >
> > > But, as LoongArch is the first architecture to not have fstat nor
> > > newfstatat, the LoongArch glibc does not attempt falling back at all
> > > when it gets -ENOSYS for statx -- and you see the problem there!
> > >
> > > Actually, back when the LoongArch port was under review, people were
> > > aware of the same problem with sandboxing clone3 [3], so clone was
> > > eventually kept. Unfortunately it seemed at that time no one had noticed
> > > statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> > > postponing the problem further), it seems inevitable that we would need
> > > to tackle seccomp deep argument inspection.
> > >
> > > However, this is obviously a decision that shouldn't be taken lightly,
> > > so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> > > in unistd.h. This is the simplest solution for now, and so we hope the
> > > community will tackle the long-standing problem of seccomp deep argument
> > > inspection in the future [4][5].
> > >
> > > More infomation please reading this thread [6].
> > >
> > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> > > [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> > > [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> > > [4] https://lwn.net/Articles/799557/
> > > [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> > > [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
> > >
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > >  arch/loongarch/include/uapi/asm/unistd.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
> > > index fcb668984f03..b344b1f91715 100644
> > > --- a/arch/loongarch/include/uapi/asm/unistd.h
> > > +++ b/arch/loongarch/include/uapi/asm/unistd.h
> > > @@ -1,4 +1,5 @@
> > >  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > +#define __ARCH_WANT_NEW_STAT
> > >  #define __ARCH_WANT_SYS_CLONE
> > >  #define __ARCH_WANT_SYS_CLONE3
> > >
> > > --
> > > 2.43.5
> > >
> > >
> >
> > What kernel branch(s) is this for?
> For 6.1~6.10.

What is the git id of this change in Linus's tree?

Re: [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

[Xi Ruoyao]

On Sun, 2024-08-11 at 17:42 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 31, 2024 at 09:06:56AM +0800, Huacai Chen wrote:
> > On Tue, Jul 30, 2024 at 10:24 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > 
> > > On Tue, Jul 30, 2024 at 10:25:42AM +0800, Huacai Chen wrote:
> > > > Chromium sandbox apparently wants to deny statx [1] so it could properly
> > > > inspect arguments after the sandboxed process later falls back to fstat.
> > > > Because there's currently not a "fd-only" version of statx, so that the
> > > > sandbox has no way to ensure the path argument is empty without being
> > > > able to peek into the sandboxed process's memory. For architectures able
> > > > to do newfstatat though, glibc falls back to newfstatat after getting
> > > > -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> > > > inspecting the path argument, transforming allowed newfstatat's into
> > > > fstat instead which is allowed and has the same type of return value.
> > > > 
> > > > But, as LoongArch is the first architecture to not have fstat nor
> > > > newfstatat, the LoongArch glibc does not attempt falling back at all
> > > > when it gets -ENOSYS for statx -- and you see the problem there!
> > > > 
> > > > Actually, back when the LoongArch port was under review, people were
> > > > aware of the same problem with sandboxing clone3 [3], so clone was
> > > > eventually kept. Unfortunately it seemed at that time no one had noticed
> > > > statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> > > > postponing the problem further), it seems inevitable that we would need
> > > > to tackle seccomp deep argument inspection.
> > > > 
> > > > However, this is obviously a decision that shouldn't be taken lightly,
> > > > so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> > > > in unistd.h. This is the simplest solution for now, and so we hope the
> > > > community will tackle the long-standing problem of seccomp deep argument
> > > > inspection in the future [4][5].
> > > > 
> > > > More infomation please reading this thread [6].
> > > > 
> > > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> > > > [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> > > > [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> > > > [4] https://lwn.net/Articles/799557/
> > > > [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> > > > [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
> > > > 
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > ---
> > > >  arch/loongarch/include/uapi/asm/unistd.h | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
> > > > index fcb668984f03..b344b1f91715 100644
> > > > --- a/arch/loongarch/include/uapi/asm/unistd.h
> > > > +++ b/arch/loongarch/include/uapi/asm/unistd.h
> > > > @@ -1,4 +1,5 @@
> > > >  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > > +#define __ARCH_WANT_NEW_STAT
> > > >  #define __ARCH_WANT_SYS_CLONE
> > > >  #define __ARCH_WANT_SYS_CLONE3
> > > > 
> > > > --
> > > > 2.43.5
> > > > 
> > > > 
> > > 
> > > What kernel branch(s) is this for?
> > For 6.1~6.10.
> 
> What is the git id of this change in Linus's tree?

https://git.kernel.org/torvalds/c/7697a0fe0154


-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: [PATCH for-stable] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

[Greg Kroah-Hartman]

On Wed, Aug 14, 2024 at 05:18:29PM +0800, Xi Ruoyao wrote:
> On Sun, 2024-08-11 at 17:42 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 31, 2024 at 09:06:56AM +0800, Huacai Chen wrote:
> > > On Tue, Jul 30, 2024 at 10:24 PM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > > 
> > > > On Tue, Jul 30, 2024 at 10:25:42AM +0800, Huacai Chen wrote:
> > > > > Chromium sandbox apparently wants to deny statx [1] so it could properly
> > > > > inspect arguments after the sandboxed process later falls back to fstat.
> > > > > Because there's currently not a "fd-only" version of statx, so that the
> > > > > sandbox has no way to ensure the path argument is empty without being
> > > > > able to peek into the sandboxed process's memory. For architectures able
> > > > > to do newfstatat though, glibc falls back to newfstatat after getting
> > > > > -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> > > > > inspecting the path argument, transforming allowed newfstatat's into
> > > > > fstat instead which is allowed and has the same type of return value.
> > > > > 
> > > > > But, as LoongArch is the first architecture to not have fstat nor
> > > > > newfstatat, the LoongArch glibc does not attempt falling back at all
> > > > > when it gets -ENOSYS for statx -- and you see the problem there!
> > > > > 
> > > > > Actually, back when the LoongArch port was under review, people were
> > > > > aware of the same problem with sandboxing clone3 [3], so clone was
> > > > > eventually kept. Unfortunately it seemed at that time no one had noticed
> > > > > statx, so besides restoring fstat/newfstatat to LoongArch uapi (and
> > > > > postponing the problem further), it seems inevitable that we would need
> > > > > to tackle seccomp deep argument inspection.
> > > > > 
> > > > > However, this is obviously a decision that shouldn't be taken lightly,
> > > > > so we just restore fstat/newfstatat by defining __ARCH_WANT_NEW_STAT
> > > > > in unistd.h. This is the simplest solution for now, and so we hope the
> > > > > community will tackle the long-standing problem of seccomp deep argument
> > > > > inspection in the future [4][5].
> > > > > 
> > > > > More infomation please reading this thread [6].
> > > > > 
> > > > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2823150
> > > > > [2] https://chromium.googlesource.com/chromium/src/sandbox/+/c085b51940bd/linux/seccomp-bpf-helpers/sigsys_handlers.cc#355
> > > > > [3] https://lore.kernel.org/linux-arch/20220511211231.GG7074@brightrain.aerifal.cx/
> > > > > [4] https://lwn.net/Articles/799557/
> > > > > [5] https://lpc.events/event/4/contributions/560/attachments/397/640/deep-arg-inspection.pdf
> > > > > [6] https://lore.kernel.org/loongarch/20240226-granit-seilschaft-eccc2433014d@brauner/T/#t
> > > > > 
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > ---
> > > > >  arch/loongarch/include/uapi/asm/unistd.h | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/arch/loongarch/include/uapi/asm/unistd.h b/arch/loongarch/include/uapi/asm/unistd.h
> > > > > index fcb668984f03..b344b1f91715 100644
> > > > > --- a/arch/loongarch/include/uapi/asm/unistd.h
> > > > > +++ b/arch/loongarch/include/uapi/asm/unistd.h
> > > > > @@ -1,4 +1,5 @@
> > > > >  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > > > +#define __ARCH_WANT_NEW_STAT
> > > > >  #define __ARCH_WANT_SYS_CLONE
> > > > >  #define __ARCH_WANT_SYS_CLONE3
> > > > > 
> > > > > --
> > > > > 2.43.5
> > > > > 
> > > > > 
> > > > 
> > > > What kernel branch(s) is this for?
> > > For 6.1~6.10.
> > 
> > What is the git id of this change in Linus's tree?
> 
> https://git.kernel.org/torvalds/c/7697a0fe0154

Thanks, now queued up.

greg k-h