linux-kernel - Re: ETXTBSY window in _

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] [day] [month] [year] [list]

Message-ID: <CAGudoHE_RFXT9n8U9X4TD_9gp-raFjXLuv9yk8eLsngi6f7YZw@mail.gmail.com>
Date: Mon, 1 Sep 2025 22:22:47 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Colin Walters <walters@...bum.org>
Cc: Alexander Monakov <amonakov@...ras.ru>, linux-fsdevel@...r.kernel.org, 
	Al Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	linux-kernel@...r.kernel.org
Subject: Re: ETXTBSY window in __fput

On Mon, Sep 1, 2025 at 9:57 PM Colin Walters <walters@...bum.org> wrote:
> On Mon, Sep 1, 2025, at 2:39 PM, Mateusz Guzik wrote:
> >
> > The O_CLOFORM idea was accepted into POSIX and recent-ish implemented in
> > all the BSDs (no, really) and illumos, but got NAKed in Linux. It's also
> > a part of pig's attire so I think that's the right call.
>
> Do you have a reference handy for that NAK?
>

https://lore.kernel.org/linux-fsdevel/20200515160342.GE23230@ZenIV.linux.org.uk/

> > To that end, my sketch of a suggestion boils down to a new API which
> > allows you to construct a new process one step at a time
>
> In this vein I think io_uring_spawn work sounds like the best: https://lwn.net/Articles/908268/
>

Indeed sounds like the same core idea, I don't understand why tie it
to io_uring though.

> However...if we predicate any solution to this problem on changing every single codebase which is spawning processes, it's going to take a long time. I think changing the few special cases around "sealing" (fsverity and write + fexecve()) is more tractable.

The problem does not concern every single codebase which spawns a
process. It concerns the few which are heavily multithreaded while
creating binaries they are about to exec.

If they have to be patched in your proposal anyway, they may as well
use the new API.

For non-affected consumers, I was mostly thinking make and shells just
from perf standpoint.
-- 
Mateusz Guzik <mjguzik gmail.com>