linux-kernel - Re: [PATCH AUTOSEL 6.6 048/139] proc: add config & param to block forcing mem writes

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: <e22f3662-c985-4409-99f3-5168fa2a4b9f@p183>
Date: Wed, 25 Sep 2024 18:58:05 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Sasha Levin <sashal@...nel.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Adrian Ratiu <adrian.ratiu@...labora.com>,
	Doug Anderson <dianders@...omium.org>, Jeff Xu <jeffxu@...gle.com>,
	Jann Horn <jannh@...gle.com>, Kees Cook <kees@...nel.org>,
	Ard Biesheuvel <ardb@...nel.org>,
	Christian Brauner <brauner@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, corbet@....net,
	paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
	thuth@...hat.com, bp@...en8.de, tglx@...utronix.de,
	jpoimboe@...nel.org, paulmck@...nel.org, tony@...mide.com,
	xiongwei.song@...driver.com, akpm@...ux-foundation.org,
	oleg@...hat.com, casey@...aufler-ca.com, viro@...iv.linux.org.uk,
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 6.6 048/139] proc: add config & param to block
 forcing mem writes

On Wed, Sep 25, 2024 at 08:07:48AM -0400, Sasha Levin wrote:
> From: Adrian Ratiu <adrian.ratiu@...labora.com>
> 
> [ Upstream commit 41e8149c8892ed1962bd15350b3c3e6e90cba7f4 ]
> 
> This adds a Kconfig option and boot param to allow removing
> the FOLL_FORCE flag from /proc/pid/mem write calls because
> it can be abused.

And this is not a mount option why?

> The traditional forcing behavior is kept as default because
> it can break GDB and some other use cases.
> 
> Previously we tried a more sophisticated approach allowing
> distributions to fine-tune /proc/pid/mem behavior, however
> that got NAK-ed by Linus [1], who prefers this simpler
> approach with semantics also easier to understand for users.