linux-kernel - Re: [REGRESSION] mold linker depends on ETXTBSY, but open(2) no longer returns it

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: <CACKH++YYM2uCOrFwELeJZzHuTn5UozE-=7PS3DiVnsJfXg1SDw@mail.gmail.com>
Date: Wed, 27 Nov 2024 07:33:53 +0900
From: Rui Ueyama <rui314@...il.com>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: brauner@...nel.org, regressions@...ts.linux.dev, 
	LKML <linux-kernel@...r.kernel.org>, 
	Linux-fsdevel <linux-fsdevel@...r.kernel.org>, Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [REGRESSION] mold linker depends on ETXTBSY, but open(2) no
 longer returns it

On Mon, Nov 11, 2024 at 9:02 PM Thorsten Leemhuis
<regressions@...mhuis.info> wrote:
>
> [adding a few CCs, dropping stable]
>
> On 28.10.24 12:15, Rui Ueyama wrote:
> > I'm the creator and the maintainer of the mold linker
> > (https://github.com/rui314/mold). Recently, we discovered that mold
> > started causing process crashes in certain situations due to a change
> > in the Linux kernel. Here are the details:
> >
> > - In general, overwriting an existing file is much faster than
> > creating an empty file and writing to it on Linux, so mold attempts to
> > reuse an existing executable file if it exists.
> >
> > - If a program is running, opening the executable file for writing
> > previously failed with ETXTBSY. If that happens, mold falls back to
> > creating a new file.
> >
> > - However, the Linux kernel recently changed the behavior so that
> > writing to an executable file is now always permitted
> > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853).
>
> FWIW, that is 2a010c41285345 ("fs: don't block i_writecount during
> exec") [v6.11-rc1] from Christian Brauner.
>
> > That caused mold to write to an executable file even if there's a
> > process running that file. Since changes to mmap'ed files are
> > immediately visible to other processes, any processes running that
> > file would almost certainly crash in a very mysterious way.
> > Identifying the cause of these random crashes took us a few days.
> >
> > Rejecting writes to an executable file that is currently running is a
> > well-known behavior, and Linux had operated that way for a very long
> > time. So, I don’t believe relying on this behavior was our mistake;
> > rather, I see this as a regression in the Linux kernel.
> >
> > Here is a bug report to the mold linker:
> > https://github.com/rui314/mold/issues/1361
>
> Thx for the report. I might be missing something, but from here it looks
> like nothing happened. So please allow me to ask:
>
> What's the status? Did anyone look into this? Is this sill happening?

Ping? I think this is a fairly major kernel regression. We can't ask
all our mold linker users to upgrade their linker before upgrading
their kernel. Isn't "Never break userland" the kernel's policy? I
wonder why no action or even a discussion has taken place so far.