Received-SPF: pass (google.com: domain of linux-kernel+bounces-80576-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <61c5b883762ba4f7fc5a89f539dcd6c8b13d8622.camel@icenowy.me>
Subject: Re: Chromium sandbox on LoongArch and statx -- seccomp deep
 argument inspection again?
From: Icenowy Zheng <uwu@icenowy.me>
To: Xi Ruoyao <xry111@xry111.site>, Huacai Chen <chenhuacai@kernel.org>, 
	WANG Xuerui <kernel@xen0n.name>
Cc: linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Christian
 Brauner <brauner@kernel.org>, Kees Cook <keescook@chromium.org>, Xuefeng Li
 <lixuefeng@loongson.cn>, Jianmin Lv <lvjianmin@loongson.cn>, Xiaotian Wu
 <wuxiaotian@loongson.cn>, WANG Rui <wangrui@loongson.cn>, Miao Wang
 <shankerwangmiao@gmail.com>, "loongarch@lists.linux.dev"
 <loongarch@lists.linux.dev>, linux-arch <linux-arch@vger.kernel.org>, Linux
 Kernel Mailing List <linux-kernel@vger.kernel.org>
Date: Mon, 26 Feb 2024 14:03:48 +0800
In-Reply-To: <24c47463f9b469bdc03e415d953d1ca926d83680.camel@xry111.site>
References: <599df4a3-47a4-49be-9c81-8e21ea1f988a@xen0n.name>
	 <CAAhV-H4oW70y-2ZSp=b-Ed3A7Jrxfg6xvO8YpjED6To=PF0NwA@mail.gmail.com>
	 <f063e65df92228cac6e57b0c21de6b750cf47e42.camel@icenowy.me>
	 <24c47463f9b469bdc03e415d953d1ca926d83680.camel@xry111.site>
Organization: Anthon Open-Source Community
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 
Precedence: bulk
MIME-Version: 1.0

=E5=9C=A8 2024-02-25=E6=98=9F=E6=9C=9F=E6=97=A5=E7=9A=84 15:32 +0800=EF=BC=
=8CXi Ruoyao=E5=86=99=E9=81=93=EF=BC=9A
> 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.
> >=20
> > 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.
>=20
> 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.

> "if the user wants fstat, give them fstat" for the performance issue:
>=20
> https://sourceware.org/pipermail/libc-alpha/2023-September/151365.html
>=20
> However we only want fstat (actually "newfstat" in fs/stat.c), and it
> seems we don't want to resurrect newstat, newlstat, newfstatat, etc.
> (or
> am I missing any benefit - performance or "just pleasing seccomp" -
> of
> them comparing to statx?) so we don't want to just define
> __ARCH_WANT_NEW_STAT.=C2=A0 So it seems we need to add some new #if to
> fs/stat.c and include/uapi/asm-generic/unistd.h.
>=20
> And no, it's not a design issue of all other syscalls.=C2=A0 It's just th=
e
> design issue of seccomp.=C2=A0 There's no way to design a syscall allowin=
g
> seccomp to inspect a 100-character path in its argument unless
> refactoring seccomp entirely because we cannot fit a 100-character
> path
> into 8 registers.

Well my meaning is that syscalls should be designed to be simple to
prevent this kind of circumstance.

>=20
> As at now people do use PTRACE_PEEKDATA for "deep inspection"
> (actually
> "debugging" the target process) but it obviously makes a very severe
> performance impact.
>=20
> <rant>
>=20
> Today the entire software industry is saying "do things in a
> declarative
> way" but seccomp is completely the opposite.=C2=A0 It's auditing *how* th=
e
> sandboxed application is doing things instead of *what* will be done.
>=20
> I've raised my against to seccomp and/or syscall allowlisting several
> times after seeing so many breakages like:
>=20
> - https://github.com/NetworkConfiguration/dhcpcd/issues/120
> - https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/252
> - https://blog.pintia.cn/2018/06/27/glibc-segmentation-fault/
> -
> http://web.archive.org/web/20210126121421/http://acm.xidian.edu.cn/discus=
s/thread.php?tid=3D148&cid=3D#
> =C2=A0(comment 3)
>=20
> but people just keep telling me "you are wrong, you don't understand
> security".=C2=A0 Some of them even complain "seccomp is broken" as well
> but
> still keep using it.
>=20
> </rant>
>=20