linux-kernel - Re: [GIT PULL for v6.11] vfs procfs

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: <CAHk-=wiGWLChxYmUA5HrT5aopZrB7_2VTa0NLZcxORgkUe5tEQ@mail.gmail.com>
Date: Mon, 15 Jul 2024 12:20:37 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL for v6.11] vfs procfs

On Fri, 12 Jul 2024 at 06:59, Christian Brauner <brauner@...nel.org> wrote:
>
> The level of fine-grained management isn't my favorite as it requires
> distributions to have some level of knowledge around the implications of
> FOLL_FORCE and /proc/<pid>/mem access in general.

Ugh.

I pulled this, and looked at it, and then I decided I can't live with
something this ugly.

First off, there is ABSOLUTELY no reason for any of this to be using
static keys, which makes an already ugly patch even uglier. None of
this is magically so performance-critical that we'd need static keys
for this kind of thing

Secondly, this is absolutely the wrong kind of nairy rat's nest of
strange conditionals made worse by pointlessly adding kernel command
line options for it.

Now, the FOLL_FORCE is unquestionably problematic. But this horror
isn't making it better - it's just obfuscating a bad situation and
making it worse.

By all means just add one single kernel config option to say "no
FOLL_FORCE in /proc/pid/mem". Or require it to *actually* be traced,
or something like that.

But not this horror.

             Linus