Received-SPF: pass (google.com: domain of linux-kernel+bounces-81317-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <6bf460d17b9f44326497ffb41e03363b112d6927.camel@xry111.site>
Subject: Re: Chromium sandbox on LoongArch and statx -- seccomp deep
 argument inspection again?
From: Xi Ruoyao <xry111@xry111.site>
To: Arnd Bergmann <arnd@arndb.de>, Icenowy Zheng <uwu@icenowy.me>, Huacai
 Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Adhemerval
 Zanella <adhemerval.zanella@linaro.org>, Rich Felker <dalias@aerifal.cx>
Cc: linux-api@vger.kernel.org, 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 19:57:56 +0800
In-Reply-To: <b9fb0de1-bfb9-47a6-9730-325e7641c182@app.fastmail.com>
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>
	 <61c5b883762ba4f7fc5a89f539dcd6c8b13d8622.camel@icenowy.me>
	 <3c396b7c-adec-4762-9584-5824f310bf7b@app.fastmail.com>
	 <6f7a8e320f3c2bd5e9b704bb8d1f311714cd8644.camel@xry111.site>
	 <b9fb0de1-bfb9-47a6-9730-325e7641c182@app.fastmail.com>
Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual;
 keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 
Precedence: bulk
MIME-Version: 1.0

On Mon, 2024-02-26 at 10:20 +0100, Arnd Bergmann wrote:

/* snip */

>=20
> > Or maybe we can just introduce a new AT_something to make statx
> > completely ignore pathname but behave like AT_EMPTY_PATH + "".
>=20
> I think this is better than going back to fstat64_time64(), but
> it's still not great because
>=20
> - all the reserved flags on statx() are by definition incompatible
> =C2=A0 with existing kernels that return -EINVAL for any flag they do
> =C2=A0 not recognize.

Oops, we are deeming passing undefined flags in "mask" undefined
behavior but not "flags", thus "wild software" may be relying on EINVAL
for invalid flags...  We *might* make this new AT_xxx a bit in mask
instead of flags but it would be very dirty IMO.

> - you still need to convince libc developers to actually use
> =C2=A0 the flag despite the backwards compatibility problem, either
> =C2=A0 with a fallback to the current behavior or a version check.

Let me ping some libc developers then...

> Using the NULL path as a fallback would solve the problem with
> seccomp, but it would not make the normal case any faster.

But "wild software" may be relying on a EFAULT for NULL path too...

/* snip */

> >=20
> > Oops.=C2=A0 I thought "newstat" should be using 64-bit time but it seem=
s the
> > "new" is not what I'd expected...=C2=A0 The "new" actually means "newer=
 than
> > Linux 0.9"! :(
> >=20
> > Let's not use "new" in future syscall names...
>=20
> Right, we definitely can't ever succeed. On some architectures
> we even had "oldstat" and "stat" before "newstat" and "stat64",
> and on some architectures we mix them up. E.g. x86_64 has fstat()
> and fstatat64() with the same structure but doesn't define
> __NR_newfstat. On mips64, there is a 'newstat' but it has 32-bit
> timestamps unlike all other 64-bit architectures.
>=20
> statx() was intended to solve these problems once and for all,
> and it appears that we have failed again.

https://xkcd.com/927/ :(

--=20
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University