From: Kees Cook <kees@kernel.org>
To: Isaac Manjarres <isaacmanjarres@google.com>
Cc: Jeff Xu <jeffxu@chromium.org>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Jann Horn <jannh@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Alexander Aring <alex.aring@gmail.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Shuah Khan <shuah@kernel.org>,
kernel-team@android.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Suren Baghdasaryan <surenb@google.com>,
Kalesh Singh <kaleshsingh@google.com>,
John Stultz <jstultz@google.com>
Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd
Date: Tue, 14 Jan 2025 13:29:44 -0800 [thread overview]
Message-ID: <202501141326.E81023D@keescook> (raw)
In-Reply-To: <Z4bC1I1GTlXiJhvS@google.com>
On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
> I think the main issue in the threat model that I described is that
> an attacking process can gain control of a more priveleged process.
I understood it to be about an attacker gaining execution control through
a rewritten function pointer, not that they already have arbitrary
execution control. (i.e. taking a "jump anywhere" primitive and
upgrading it to "execute anything".) Is the expectation that existing
ROP/JOP techniques make protecting memfd irrelevant?
--
Kees Cook
next prev parent reply other threads:[~2025-01-14 21:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 1:09 [RFC PATCH v1 0/2] Add file seal to prevent future exec mappings Isaac J. Manjarres
2024-12-06 1:09 ` [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd Isaac J. Manjarres
2024-12-06 17:49 ` Kalesh Singh
2024-12-06 20:50 ` Isaac Manjarres
2024-12-06 18:19 ` Lorenzo Stoakes
2024-12-06 20:48 ` Isaac Manjarres
2024-12-06 21:14 ` Lorenzo Stoakes
2024-12-11 20:56 ` Isaac Manjarres
2025-01-03 15:13 ` Jann Horn
2025-01-06 18:26 ` Jeff Xu
2025-01-07 0:44 ` Kees Cook
2025-01-08 19:06 ` Lorenzo Stoakes
2025-01-08 22:07 ` Kees Cook
2025-01-09 23:30 ` Jeff Xu
2025-01-14 20:02 ` Isaac Manjarres
2025-01-14 21:29 ` Kees Cook [this message]
2025-01-14 22:42 ` Isaac Manjarres
2025-01-14 23:41 ` Jeff Xu
2025-01-14 23:56 ` Jeff Xu
2024-12-06 1:09 ` [RFC PATCH v1 2/2] selftests/memfd: Add tests for F_SEAL_FUTURE_EXEC Isaac J. Manjarres
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=202501141326.E81023D@keescook \
--to=kees@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alex.aring@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=isaacmanjarres@google.com \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jlayton@kernel.org \
--cc=jstultz@google.com \
--cc=kaleshsingh@google.com \
--cc=kernel-team@android.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.