Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument inspection again?
From: Christian Brauner <brauner@kernel.org>
Date: 2024-02-26 08:26:45
Also in:
linux-arch, lkml, loongarch
From: Christian Brauner <brauner@kernel.org>
Date: 2024-02-26 08:26:45
Also in:
linux-arch, lkml, loongarch
On Mon, Feb 26, 2024 at 02:03:48PM +0800, Icenowy Zheng wrote:
在 2024-02-25星期日的 15:32 +0800,Xi Ruoyao写道:quoted
On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote:quoted
quoted
From my point of view, I prefer to "restore fstat", because we need to use the Chrome sandbox everyday (even though it hasn't been upstream by now). But I also hope "seccomp deep argument inspection" can be solved in the future.My idea is this problem needs syscalls to be designed with deep argument inspection in mind; syscalls before this should be considered as historical error and get fixed by resotring old syscalls.I'd not consider fstat an error as using statx for fstat has a performance impact (severe for some workflows), and Linus has concludedSorry for clearance, I mean statx is an error in ABI design, not fstat.
We will not be limited arbitrarly in system call design by seccomp being unable to do deep argument inspection. That ship has sailed many years ago. And it's a bit laughable to disalow pointer arguments and structs in system calls because seccomp isn't able to inspect them.