Hi, Arnd,
On Sat, May 11, 2024 at 8:17 PM Arnd Bergmann arnd@arndb.de 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