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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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