From: "Theo de Raadt" <deraadt@openbsd.org>
To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
Jeff Xu <jeffxu@chromium.org>, Jeff Xu <jeffxu@google.com>,
Jonathan Corbet <corbet@lwn.net>,
akpm@linux-foundation.org, keescook@chromium.org,
jannh@google.com, sroettger@google.com, willy@infradead.org,
gregkh@linuxfoundation.org, torvalds@linux-foundation.org,
usama.anjum@collabora.com, rdunlap@infradead.org,
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
Subject: Re: [PATCH v8 0/4] Introduce mseal
Date: Fri, 02 Feb 2024 12:32:16 -0700 [thread overview]
Message-ID: <85714.1706902336@cvs.openbsd.org> (raw)
In-Reply-To: <20240202192137.6lupguvhtdt72rbr@revolver>
> What I'm more concerned about is what happens if you call mseal() on a
> range and it can mseal a portion. Like, what happens to the first vma
> in your test_seal_unmapped_middle case? I see it returns an error, but
> is the first VMA mseal()'ed? (no it's not, but test that)
That is correct, Liam.
Unix system calls must be atomic.
They either return an error, and that is a promise they made no changes.
Or they do the work required, and then return success.
In OpenBSD, all mimmutable() aspects were carefully studied to gaurantee
this behaviour.
I am not an expert in the Linux kernel to make the assessment; someone
who is qualified must make that assessment. Fuzzing with tests is a good
way to judge it simpler.
next prev parent reply other threads:[~2024-02-02 19:32 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 17:50 [PATCH v8 0/4] Introduce mseal jeffxu
2024-01-31 17:50 ` [PATCH v8 1/4] mseal: Wire up mseal syscall jeffxu
2024-01-31 17:50 ` [PATCH v8 2/4] mseal: add " jeffxu
2024-02-01 23:11 ` Eric Biggers
2024-02-02 3:30 ` Jeff Xu
2024-02-02 3:54 ` Theo de Raadt
2024-02-02 4:03 ` Jeff Xu
2024-02-02 4:10 ` Theo de Raadt
2024-02-02 4:22 ` Jeff Xu
2024-01-31 17:50 ` [PATCH v8 3/4] selftest mm/mseal memory sealing jeffxu
2024-01-31 17:50 ` [PATCH v8 4/4] mseal:add documentation jeffxu
2024-01-31 19:34 ` [PATCH v8 0/4] Introduce mseal Liam R. Howlett
2024-02-01 1:27 ` Jeff Xu
2024-02-01 1:46 ` Theo de Raadt
2024-02-01 16:56 ` Bird, Tim
2024-02-01 1:55 ` Theo de Raadt
2024-02-01 20:45 ` Liam R. Howlett
2024-02-01 22:24 ` Theo de Raadt
2024-02-02 1:06 ` Greg KH
2024-02-02 3:24 ` Jeff Xu
2024-02-02 3:29 ` Linus Torvalds
2024-02-02 3:46 ` Jeff Xu
2024-02-02 15:18 ` Greg KH
2024-02-01 22:37 ` Jeff Xu
2024-02-01 22:54 ` Theo de Raadt
2024-02-01 23:15 ` Linus Torvalds
2024-02-01 23:43 ` Theo de Raadt
2024-02-02 0:26 ` Theo de Raadt
2024-02-02 3:20 ` Jeff Xu
2024-02-02 4:05 ` Theo de Raadt
2024-02-02 4:54 ` Jeff Xu
2024-02-02 5:00 ` Theo de Raadt
2024-02-02 17:58 ` Jeff Xu
2024-02-02 18:51 ` Pedro Falcato
2024-02-02 21:20 ` Jeff Xu
2024-02-04 19:39 ` David Laight
2024-02-02 17:05 ` Theo de Raadt
2024-02-02 21:02 ` Jeff Xu
2024-02-02 3:14 ` Jeff Xu
2024-02-02 15:13 ` Liam R. Howlett
2024-02-02 17:24 ` Jeff Xu
2024-02-02 19:21 ` Liam R. Howlett
2024-02-02 19:32 ` Theo de Raadt [this message]
2024-02-02 20:36 ` Linus Torvalds
2024-02-02 20:57 ` Jeff Xu
2024-02-02 21:18 ` Liam R. Howlett
2024-02-02 23:36 ` Linus Torvalds
2024-02-03 4:45 ` Liam R. Howlett
2024-02-05 22:13 ` Suren Baghdasaryan
2024-02-02 20:14 ` 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=85714.1706902336@cvs.openbsd.org \
--to=deraadt@openbsd.org \
--cc=Liam.Howlett@Oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--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=pedro.falcato@gmail.com \
--cc=rdunlap@infradead.org \
--cc=sroettger@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 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.