Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Feb 26, 2024, at 14:32, Christian Brauner wrote:
> On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote:
>
> What this tells me without knowing the exact reason is that they thought
> "Oh, if we just return ENOSYS then the workload or glibc will just
> always be able to fallback to fstat() or fstatat()". Which ultimately is
> the exact same thing that containers often assume.
>
> So really, just skipping on various system calls isn't going to work.
> You can't just implement new system calls and forget about the rest
> unless you know exactly what workloads your architecure will run on.
>
> Please implement fstat() or fstatat() and stop inventing hacks for
> statx() to make weird sandboxing rules work, please.

Do you mean we should add fstat64_time64() for all architectures
then? Would use use the same structure layout as statx for this,
the 64-bit version of the 'struct stat' layout from
include/uapi/asm-generic/stat.h, or something new that solves
the same problems?

I definitely don't want to see a new time32 API added to
mips64 and the 32-bit architectures, so the existing stat64
interface won't work as a statx replacement.

     Arnd