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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240226-granit-seilschaft-eccc2433014d@brauner>
Date: Mon, 26 Feb 2024 09:26:38 +0100
From: Christian Brauner <brauner@...nel.org>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: Xi Ruoyao <xry111@...111.site>, Huacai Chen <chenhuacai@...nel.org>, 
	WANG Xuerui <kernel@...0n.name>, linux-api@...r.kernel.org, Arnd Bergmann <arnd@...db.de>, 
	Kees Cook <keescook@...omium.org>, Xuefeng Li <lixuefeng@...ngson.cn>, 
	Jianmin Lv <lvjianmin@...ngson.cn>, Xiaotian Wu <wuxiaotian@...ngson.cn>, 
	WANG Rui <wangrui@...ngson.cn>, Miao Wang <shankerwangmiao@...il.com>, 
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, linux-arch <linux-arch@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Chromium sandbox on LoongArch and statx -- seccomp deep argument
 inspection again?

On Mon, Feb 26, 2024 at 02:03:48PM +0800, Icenowy Zheng wrote:
> 在 2024-02-25星期日的 15:32 +0800，Xi Ruoyao写道：
> > On Sun, 2024-02-25 at 14:51 +0800, Icenowy Zheng wrote:
> > > > 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
> > concluded
> 
> Sorry 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.