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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx/ > > > [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@xxxxxxxxxxxxxxx > > > Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx> > > > --- > > > 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?
