From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: akpm@linux-foundation.org, torvalds@linux-foundation.org,
jeffxu@chromium.org
Cc: keescook@chromium.org, jannh@google.com, sroettger@google.com,
willy@infradead.org, gregkh@linuxfoundation.org,
usama.anjum@collabora.com, corbet@lwn.net, surenb@google.com,
merimus@google.com, rdunlap@infradead.org, jeffxu@google.com,
jorgelo@chromium.org, groeck@chromium.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, pedro.falcato@gmail.com,
dave.hansen@intel.com, linux-hardening@vger.kernel.org,
deraadt@openbsd.org
Subject: Re: [PATCH v10 2/5] mseal: add mseal syscall
Date: Tue, 16 Apr 2024 10:59:34 -0400 [thread overview]
Message-ID: <v22gngid25vcufvdfbv3pdymq3s72c47pizr23tkrmbbyiqoe4@y5yxseh6thnf> (raw)
In-Reply-To: <20240415163527.626541-3-jeffxu@chromium.org>
* jeffxu@chromium.org <jeffxu@chromium.org> [240415 12:35]:
> From: Jeff Xu <jeffxu@chromium.org>
>
> The new mseal() is an syscall on 64 bit CPU, and with
> following signature:
>
> int mseal(void addr, size_t len, unsigned long flags)
> addr/len: memory range.
> flags: reserved.
>
> mseal() blocks following operations for the given memory range.
>
> 1> Unmapping, moving to another location, and shrinking the size,
> via munmap() and mremap(), can leave an empty space, therefore can
> be replaced with a VMA with a new set of attributes.
>
> 2> Moving or expanding a different VMA into the current location,
> via mremap().
>
> 3> Modifying a VMA via mmap(MAP_FIXED).
>
> 4> Size expansion, via mremap(), does not appear to pose any specific
> risks to sealed VMAs. It is included anyway because the use case is
> unclear. In any case, users can rely on merging to expand a sealed VMA.
>
> 5> mprotect() and pkey_mprotect().
>
> 6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous
> memory, when users don't have write permission to the memory. Those
> behaviors can alter region contents by discarding pages, effectively a
> memset(0) for anonymous memory.
>
> Following input during RFC are incooperated into this patch:
>
> Jann Horn: raising awareness and providing valuable insights on the
> destructive madvise operations.
> Linus Torvalds: assisting in defining system call signature and scope.
> Liam R. Howlett: perf optimization.
> Theo de Raadt: sharing the experiences and insight gained from
> implementing mimmutable() in OpenBSD.
>
> Finally, the idea that inspired this patch comes from Stephen Röttger’s
> work in Chrome V8 CFI.
No per-vma change is checked prior to entering a per-vma modification
loop today. This means that mseal() differs in behaviour in "up-front
failure" vs "partial change failure" that exists in every other
function.
I'm not saying it's wrong or that it's right - I'm just wondering what
the direction is here. Either we should do as much up-front as
possible or keep with tradition and have (partial) success where
possible.
If you look at do_mprotect_pkey(), you can even see
map_deny_write_exec() being checked in a loop during modifications.
I think we can all agree that having some up-front and some later
without any reason will lead to a higher probability of things getting
missed.
Thanks,
Liam
next prev parent reply other threads:[~2024-04-16 15:01 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 16:35 [PATCH v10 0/5] Introduce mseal jeffxu
2024-04-15 16:35 ` [PATCH v10 1/5] mseal: Wire up mseal syscall jeffxu
2024-04-15 18:12 ` Muhammad Usama Anjum
2024-04-15 18:21 ` Linus Torvalds
2024-04-15 19:06 ` Jeff Xu
2024-04-15 16:35 ` [PATCH v10 2/5] mseal: add " jeffxu
2024-04-16 14:59 ` Liam R. Howlett [this message]
2024-04-16 15:17 ` Jann Horn
2024-04-16 16:42 ` Theo de Raadt
2024-04-15 16:35 ` [PATCH v10 3/5] selftest mm/mseal memory sealing jeffxu
2024-04-15 18:32 ` Muhammad Usama Anjum
2024-04-15 20:27 ` Jeff Xu
2024-04-16 0:34 ` Kees Cook
2024-05-02 11:24 ` Ryan Roberts
2024-05-02 15:18 ` Jeff Xu
2024-05-02 22:39 ` Jeff Xu
2024-05-03 8:30 ` Ryan Roberts
2024-04-15 16:35 ` [PATCH v10 4/5] mseal:add documentation jeffxu
2024-04-15 16:35 ` [PATCH v10 5/5] selftest mm/mseal read-only elf memory segment jeffxu
2024-04-16 15:13 ` [PATCH v10 0/5] Introduce mseal Liam R. Howlett
2024-04-16 19:40 ` Jeff Xu
2024-04-18 20:19 ` Suren Baghdasaryan
2024-04-19 1:22 ` Jeff Xu
2024-04-19 14:57 ` Suren Baghdasaryan
2024-04-19 15:14 ` Jeff Xu
2024-04-19 16:54 ` Suren Baghdasaryan
2024-04-19 17:59 ` Pedro Falcato
2024-04-20 1:23 ` Jeff Xu
2024-05-14 17:46 ` Andrew Morton
2024-05-14 19:52 ` Kees Cook
2024-05-14 20:59 ` Jonathan Corbet
2024-05-14 21:28 ` Matthew Wilcox
2024-05-14 22:48 ` Theo de Raadt
2024-05-14 23:01 ` Andrew Morton
2024-05-14 23:47 ` Theo de Raadt
2024-05-15 2:58 ` Willy Tarreau
2024-05-15 3:36 ` Linus Torvalds
2024-05-15 4:14 ` Linus Torvalds
2024-05-15 6:14 ` Willy Tarreau
2024-05-15 0:43 ` Linus Torvalds
2024-05-15 0:57 ` Theo de Raadt
2024-05-15 1:20 ` Linus Torvalds
2024-05-15 1:47 ` Theo de Raadt
2024-05-15 2:28 ` Linus Torvalds
2024-05-15 2:42 ` Theo de Raadt
2024-05-15 4:53 ` Liam R. Howlett
2024-05-14 21:28 ` Liam R. Howlett
2024-05-15 17:18 ` Jeff Xu
2024-05-15 22:19 ` Liam R. Howlett
2024-05-16 0:59 ` 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=v22gngid25vcufvdfbv3pdymq3s72c47pizr23tkrmbbyiqoe4@y5yxseh6thnf \
--to=liam.howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=deraadt@openbsd.org \
--cc=gregkh@linuxfoundation.org \
--cc=groeck@chromium.org \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=merimus@google.com \
--cc=pedro.falcato@gmail.com \
--cc=rdunlap@infradead.org \
--cc=sroettger@google.com \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=usama.anjum@collabora.com \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).