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: <CABi2SkX--gf8XtzBd1G7wS6E=F51rFckP62V0GrONuXs1TCOcQ@mail.gmail.com>
Date: Wed, 15 Jan 2025 12:20:59 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Kees Cook <kees@...nel.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

Hi Lorenzo

On Wed, Jan 15, 2025 at 11:46 AM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> Jeff,
>
> My name is Lorenzo, not Lorenze.
>
I apologize.

> I've made it abundantly clear that this (NACKed) series cannot allow the
> kernel to be in a broken state even if a user sets flags to do so.
>
> This is because users might lack context to make this decision and
> incorrectly do so, and now we ship a known-broken kernel.
>
> You are now suggesting disabling the !CRIU requirement. Which violates my
> _requirements_ (not optional features).
>
Sure, I can add CRIU back.

Are you fine with UML and gViso not working under this CONFIG ?
UML/gViso doesn't use any KCONFIG like CRIU does.

> 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.
>
> 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.
>
Can you clarify on the definition of "broken kernel configuration":

Do you consider "setting mseal kernel cmd line under 32 bit build" as broken ?
If so, this problem is not solvable and I might just not try to solve
it for the next version.

If you just refer to a need to detect CRIU, in KCONFIG or/and kernel
cmd line,  this is solvable.

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

> You seem to have eliminated that from your summary as if the very thing
> that makes this series NACKed were not pertinent.
>
In my last email, I tried to cover all code-logic related comments,
which is blocking me.
I also mentioned I will address non-code related comments
(threat-model/test etc),  later.

> if you do not address these correctly, I will simply have to reject your v5
> too and it'll waste everybody's time. I _genuinely_ don't want to have to
> do this.
>
> Any solution MUST fulfil these requirements. I also want to see v5 as an
> RFC honestly at this stage, since it seems we are VERY MUCH in a discussion
> phase rather than a patch phase at this time.
>
Sure.

> I really want to help you improve mseal and get things upstream, but I
> can't ignore my duty to ensure that the kernel remains stable and we don't
> hand kernel users (overly huge) footguns. I hate to be negative, but this
> is why I am pushing back so much here.
>
Thanks. You can help me by answering my questions, and clarify your
requirements. I appreciate your time to make this feature useful.

Please take note that the security feature often takes away
capabilities.  Sometimes it is impossible to meet security, usability
or performance goals simultaneously. I'm trying my best to get all
aspected satisfied.

-Jeff

> Thanks!