linux-kernel - Re: [PATCH v4 1/1] exec: seal system mappings

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: <202501161142.FBA5CDA116@keescook>
Date: Thu, 16 Jan 2025 11:44:54 -0800
From: Kees Cook <kees@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Jeff Xu <jeffxu@...omium.org>, akpm@...ux-foundation.org,
	jannh@...gle.com, torvalds@...ux-foundation.org,
	adhemerval.zanella@...aro.org, oleg@...hat.com,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
	linux-mm@...ck.org, jorgelo@...omium.org, sroettger@...gle.com,
	ojeda@...nel.org, adobriyan@...il.com, anna-maria@...utronix.de,
	mark.rutland@....com, linus.walleij@...aro.org, Jason@...c4.com,
	deller@....de, rdunlap@...radead.org, davem@...emloft.net,
	hch@....de, peterx@...hat.com, hca@...ux.ibm.com,
	f.fainelli@...il.com, gerg@...nel.org, dave.hansen@...ux.intel.com,
	mingo@...nel.org, ardb@...nel.org, Liam.Howlett@...cle.com,
	mhocko@...e.com, 42.hyeyoo@...il.com, peterz@...radead.org,
	ardb@...gle.com, enh@...gle.com, rientjes@...gle.com,
	groeck@...omium.org, mpe@...erman.id.au,
	Vlastimil Babka <vbabka@...e.cz>, Andrei Vagin <avagin@...il.com>,
	Dmitry Safonov <0x7f454c46@...il.com>,
	Mike Rapoport <mike.rapoport@...il.com>,
	Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>,
	Benjamin Berg <benjamin@...solutions.net>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings

On Thu, Jan 16, 2025 at 03:34:40PM +0000, Lorenzo Stoakes wrote:
> This was originally addressed with config flags, but then boot options were
> provided which completely overrode this.
> [...]
> Again, I have no objection to a version of this series which explicitly
> disallows known-broken scenarios.

Okay, thanks. Honestly, it will motivate me to finally make CRIU a boot
param too. I'd like to run distro kernels but keep CRIU fully disabled
(it provides some "extra" introspection of seccomp filters that feels
wrong to me, but is needed for CRIU -- but I don't use CRIU...)

-- 
Kees Cook