From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Jeff Xu <jeffxu@chromium.org>
Cc: Kees Cook <kees@kernel.org>,
akpm@linux-foundation.org, jannh@google.com,
torvalds@linux-foundation.org, adhemerval.zanella@linaro.org,
oleg@redhat.com, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org, linux-mm@kvack.org,
jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org,
adobriyan@gmail.com, anna-maria@linutronix.de,
mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com,
deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net,
hch@lst.de, peterx@redhat.com, hca@linux.ibm.com,
f.fainelli@gmail.com, gerg@kernel.org,
dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org,
Liam.Howlett@oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com,
peterz@infradead.org, ardb@google.com, enh@google.com,
rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au,
Vlastimil Babka <vbabka@suse.cz>, Andrei Vagin <avagin@gmail.com>,
Dmitry Safonov <0x7f454c46@gmail.com>,
Mike Rapoport <mike.rapoport@gmail.com>,
Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
Benjamin Berg <benjamin@sipsolutions.net>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings
Date: Wed, 15 Jan 2025 19:46:00 +0000 [thread overview]
Message-ID: <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> (raw)
In-Reply-To: <CABi2SkXS9OOwP2BZGQOa=Pn+NoL1VmOJBJEn-6tWBBQwLtpYiw@mail.gmail.com>
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!
next prev parent reply other threads:[~2025-01-15 19:46 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 20:20 [PATCH v4 0/1] Seal " jeffxu
2024-11-25 20:20 ` [PATCH v4 1/1] exec: seal " jeffxu
2024-11-25 20:40 ` Matthew Wilcox
2024-12-02 17:22 ` Jeff Xu
2024-12-02 17:57 ` Lorenzo Stoakes
2024-12-02 20:05 ` Jeff Xu
2024-12-02 19:57 ` Jeff Xu
2024-12-02 18:29 ` Lorenzo Stoakes
2024-12-02 20:38 ` Jeff Xu
2024-12-03 7:35 ` Lorenzo Stoakes
2024-12-03 18:19 ` Jeff Xu
2024-12-03 20:16 ` Lorenzo Stoakes
2024-12-04 14:04 ` Benjamin Berg
2024-12-04 17:43 ` Jeff Xu
2024-12-04 18:24 ` Benjamin Berg
2024-12-10 4:12 ` Andrei Vagin
2024-12-11 22:46 ` Jeff Xu
2024-12-13 6:33 ` Andrei Vagin
2024-12-16 18:35 ` Jeff Xu
2024-12-16 18:56 ` Liam R. Howlett
2024-12-16 20:20 ` Jeff Xu
2024-12-17 22:18 ` Kees Cook
2025-01-02 19:15 ` Andrei Vagin
2025-01-03 20:48 ` Liam R. Howlett
2025-01-07 1:17 ` Kees Cook
2025-02-04 18:17 ` Johannes Berg
2025-01-03 21:38 ` Lorenzo Stoakes
2025-01-07 1:12 ` Kees Cook
2025-01-13 21:26 ` Jeff Xu
2025-01-14 4:19 ` Matthew Wilcox
2025-01-15 19:02 ` Jeff Xu
2025-01-15 19:46 ` Lorenzo Stoakes [this message]
2025-01-15 20:20 ` Jeff Xu
2025-01-16 15:48 ` Lorenzo Stoakes
2025-01-16 17:01 ` Benjamin Berg
2025-01-16 17:16 ` Lorenzo Stoakes
2025-01-16 17:18 ` Pedro Falcato
2025-01-17 18:20 ` Jeff Xu
2025-01-17 19:35 ` enh
2025-01-17 20:15 ` Jeff Xu
2025-01-17 22:08 ` Liam R. Howlett
2025-01-21 15:38 ` enh
2025-01-22 17:23 ` Liam R. Howlett
2025-01-22 22:29 ` enh
2025-01-23 8:40 ` Vlastimil Babka
2025-01-23 21:50 ` enh
2025-01-23 22:38 ` Matthew Wilcox
2025-02-06 14:19 ` enh
2025-02-06 13:20 ` Thomas Weißschuh
2025-02-06 14:38 ` enh
2025-02-06 15:28 ` Thomas Weißschuh
2025-02-06 15:51 ` enh
2025-02-06 16:37 ` Thomas Weißschuh
2025-01-17 18:08 ` Jeff Xu
2025-01-15 23:52 ` Kees Cook
2025-01-16 5:26 ` Christoph Hellwig
2025-01-16 19:40 ` Kees Cook
2025-01-17 10:14 ` Heiko Carstens
2025-01-16 15:34 ` Lorenzo Stoakes
2025-01-16 19:44 ` Kees Cook
2024-11-26 16:39 ` [PATCH v4 0/1] Seal " Lorenzo Stoakes
2024-12-02 17:28 ` Jeff Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=0x7f454c46@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@oracle.com \
--cc=adhemerval.zanella@linaro.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=anna-maria@linutronix.de \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=avagin@gmail.com \
--cc=benjamin@sipsolutions.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=enh@google.com \
--cc=f.fainelli@gmail.com \
--cc=gerg@kernel.org \
--cc=groeck@chromium.org \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jorgelo@chromium.org \
--cc=kees@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mike.rapoport@gmail.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=sroettger@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox