linux-kernel - Re: [PATCH 2/2] vfs: support statx(..., NULL, AT_EMPTY

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240703-begossen-extrem-6ed55a165113@brauner>
Date: Wed, 3 Jul 2024 20:14:15 +0200
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Xi Ruoyao <xry111@...111.site>, libc-alpha@...rceware.org, 
	"Andreas K. Huettel" <dilfridge@...too.org>, Arnd Bergmann <arnd@...db.de>, 
	Huacai Chen <chenhuacai@...nel.org>, Mateusz Guzik <mjguzik@...il.com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, io-uring@...r.kernel.org, Jens Axboe <axboe@...nel.dk>, 
	loongarch@...ts.linux.dev
Subject: Re: [PATCH 2/2] vfs: support statx(..., NULL, AT_EMPTY_PATH, ...)

On Wed, Jul 03, 2024 at 10:54:53AM GMT, Linus Torvalds wrote:
> On Wed, 3 Jul 2024 at 10:40, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Oh wow. Shows just *how* long ago that was - and how long ago I looked
> > at 32-bit code. Because clearly, I was wrong.
> 
> Ok, so clearly any *new* 32-bit architecture should use 'struct statx'
> as 'struct stat', and at least avoid the conversion pain.
> 
> Of course, if using <asm-generic/stat.h> like loongarch does, that is
> very much not what happens. You get those old models with just 'long'.
> 
> So any architecture that didn't do that 'stat == statx' and has
> binaries with old stat models should just continue to have them.
> 
> It's not like we can get rid of the kernel side code for that all _anyway_.

Fwiw, the original motivation for that whole "let's do NULL with
AT_EMPTY_PATH" (somewhat independent from the generic use of it) that
somehow morphed into this discussion was that the Chrome Sandbox has
rewrites fstatat() system calls to fstat() via SECCOMP_RET_TRAP:

  if (args.nr == __NR_fstatat_default) {
    if (*reinterpret_cast<const char*>(args.args[1]) == '\0' &&
        args.args[3] == static_cast<uint64_t>(AT_EMPTY_PATH)) {
      return syscall(__NR_fstat_default, static_cast<int>(args.args[0]),
                     reinterpret_cast<default_stat_struct*>(args.args[2]));
    }

while also disabling statx() completely because they can't (easily)
rewrite it and don't want to allow it unless we have NULL for
AT_EMPTY_PATH (which we'll have soon ofc).

In any case in [1] I proposed they add back fstat()/fstatat64() which
should get that problem solved because they can rewrite that thing.

In any case, which one of these does a new architecture have to add for
reasonable backward compatibility:

fstat()
fstat64()
fstatat64()

lstat()
lstat64()

stat()
stat64()
statx()

newstat()
newlstat()
newfstat()
newfstatat()

Because really that's a complete mess and we have all sorts of overflow
issues and odd failures in the varioius variants. And the userspace
ifdefery in libcs is just as bad if not very much worse.

[1]: https://lore.kernel.org/lkml/20240226-altmodisch-gedeutet-91c5ba2f6071@brauner