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]
Date: Sat, 11 May 2024 14:17:08 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Huacai Chen" <chenhuacai@...ngson.cn>,
 "Huacai Chen" <chenhuacai@...nel.org>
Cc: loongarch@...ts.linux.dev, Linux-Arch <linux-arch@...r.kernel.org>,
 "Xuefeng Li" <lixuefeng@...ngson.cn>, guoren <guoren@...nel.org>,
 "WANG Xuerui" <kernel@...0n.name>, "Jiaxun Yang" <jiaxun.yang@...goat.com>,
 linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn,
 stable@...r.kernel.org
Subject: Re: [PATCH] LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h

On Sat, May 11, 2024, at 12:01, Huacai Chen wrote:
> Chromium sandbox apparently wants to deny statx [1] so it could properly
> inspect arguments after the sandboxed process later falls back to fstat.
> Because there's currently not a "fd-only" version of statx, so that the
> sandbox has no way to ensure the path argument is empty without being
> able to peek into the sandboxed process's memory. For architectures able
> to do newfstatat though, glibc falls back to newfstatat after getting
> -ENOSYS for statx, then the respective SIGSYS handler [2] takes care of
> inspecting the path argument, transforming allowed newfstatat's into
> fstat instead which is allowed and has the same type of return value.
>
> But, as LoongArch is the first architecture to not have fstat nor
> newfstatat, the LoongArch glibc does not attempt falling back at all
> when it gets -ENOSYS for statx -- and you see the problem there!

My main objection here is that this is inconsistent with 32-bit
architectures: we normally have newfstatat() on 64-bit
architectures but fstatat64() on 32-bit ones. While loongarch64
is the first 64-bit one that is missing newfstatat(), we have
riscv32 already without fstatat64().

Importantly, we can't just add fstatat64() on riscv32 because
there is no time64 version for it other than statx(), and I don't
want the architectures to diverge more than necessary.
I would not mind adding a variant of statx() that works for
both riscv32 and loongarch64 though, if it gets added to all
architectures.

      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ