On Sat, 2024-06-15 at 13:47 +0200, Arnd Bergmann wrote:
/* snip */
We can only wait for the seccomp side to be fixed now? Or we can get this patch upstream for LoongArch64 at the moment, and wait for seccomp to fix RISCV32 (and LoongArch32) in future?
I'm wondering why not just introduce a new syscall or extend statx with a new flag, as we've discussed many times. They have their own disadvantages but better than this, IMO.
We should move things forward, in any way. :)
Wouldn't it be sufficient to move the AT_EMPTY_PATH hack from vfs_fstatat() to vfs_statx() so we can make them behave the same way?
As far as I can tell, the only difference between the two is that fstatat64() and similar already has added the check for zero-length strings in order to make using vfs_fstatat() fast and safe when called from glibc stat().
Do you mean https://git.kernel.org/torvalds/c/9013c51c630a? It (only partially) fix the performance issue but it won't help seccomp. The problem is you cannot check if the string is zero-length with seccomp. Thus seccomp cannot audit fstatat properly as well.
In [Firefox] *all* fstatat (and statx) calls are trapped and *the signal handler* audit this fstatat call. If flags & AT_EMPTY_PATH and path is zero-length, it calls fstat to do the job. But on LoongArch there is no way to "do the job" as the only stat-family call is statx.
[Firefox]:https://searchfox.org/mozilla-central/source/security/sandbox/linux/SandboxF...