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: <6bf460d17b9f44326497ffb41e03363b112d6927.camel@xry111.site>
Date: Mon, 26 Feb 2024 19:57:56 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Arnd Bergmann <arnd@...db.de>, Icenowy Zheng <uwu@...nowy.me>, Huacai
 Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>, Adhemerval
 Zanella <adhemerval.zanella@...aro.org>, Rich Felker <dalias@...ifal.cx>
Cc: linux-api@...r.kernel.org, Christian Brauner <brauner@...nel.org>, 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, 2024-02-26 at 10:20 +0100, Arnd Bergmann wrote:

/* snip */

> 
> > Or maybe we can just introduce a new AT_something to make statx
> > completely ignore pathname but behave like AT_EMPTY_PATH + "".
> 
> I think this is better than going back to fstat64_time64(), but
> it's still not great because
> 
> - all the reserved flags on statx() are by definition incompatible
>   with existing kernels that return -EINVAL for any flag they do
>   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
>   the flag despite the backwards compatibility problem, either
>   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 */

> > 
> > Oops.  I thought "newstat" should be using 64-bit time but it seems the
> > "new" is not what I'd expected...  The "new" actually means "newer than
> > Linux 0.9"! :(
> > 
> > Let's not use "new" in future syscall names...
> 
> 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.
> 
> statx() was intended to solve these problems once and for all,
> and it appears that we have failed again.

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

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