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: <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local>
Date: Wed, 15 Jan 2025 19:46:00 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jeff Xu <jeffxu@...omium.org>
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

Jeff,

My name is Lorenzo, not Lorenze.

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).

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.

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

You seem to have eliminated that from your summary as if the very thing
that makes this series NACKed were not pertinent.

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.

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!