Hi, Arnd, On Sat, May 11, 2024 at 8:17 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Sat, May 11, 2024, at 12:01, 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! > > My main objection here is that this is inconsistent with 32-bit > architectures: we normally have newfstatat() on 64-bit > architectures but fstatat64() on 32-bit ones. While loongarch64 > is the first 64-bit one that is missing newfstatat(), we have > riscv32 already without fstatat64(). Then how to move forward? Xuerui said that he wants to improve seccomp, but a long time has already passed. And I think we should solve this problem before Debian loong64 ports become usable. > > Importantly, we can't just add fstatat64() on riscv32 because > there is no time64 version for it other than statx(), and I don't > want the architectures to diverge more than necessary. > I would not mind adding a variant of statx() that works for > both riscv32 and loongarch64 though, if it gets added to all > architectures. As far as I know, Ren Guo is trying to implement riscv64 kernel + riscv32 userspace, so I think riscv32 kernel won't be widely used? Huacai > > Arnd >
