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: <202501151538.3E757401@keescook>
Date: Wed, 15 Jan 2025 15:52:23 -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 Wed, Jan 15, 2025 at 07:46:00PM +0000, Lorenzo Stoakes wrote:
> You are now suggesting disabling the !CRIU requirement. Which violates my
> _requirements_ (not optional features).

Why not make this simply incremental? The feature isn't intended to work
with CRIU. Why don't we get the feature in first, with a !CRUI depends?
This lets the users of this feature actually use it.

> You seem to be saying you're pushing an internal feature on upstream and
> only care about internal use cases, this is not how upstream works, as
> Matthew alludes to.

Internal? No. Chrome OS and Android. Linux runs more Android devices
than everything else in the world combined -- this is not some random
experiment.

I really don't like the feature creep nature of the system mapping
sealing reviews. There's nothing special here -- we have plenty of
features that conflict with other features. And we have a long history
in the kernel of landing the core changes with lots of conflict depends
that we then resolve as we move forward.

Why not just make system map sealing conflict with CRIU? Who is asking
to use both at the same time?

> I have told you that my requirements are:
> 
> 1. You cannot allow a user to set config or boot options to have a
>    broken kernel configuration.

What do you define as a "broken kernel configuration"?

> 2. You must provide evidence that the arches you claim work with this,
>    actually do.

What evidence would you find sufficient? I'm concerned this is turning
into a rock fetching quest.

-Kees

-- 
Kees Cook