From: valdis.kletnieks@vt.edu
To: Joel Fernandes <joel@joelfernandes.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
kernel-team <kernel-team@android.com>,
John Reck <jreck@google.com>,
John Stultz <john.stultz@linaro.org>,
Todd Kjos <tkjos@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Daniel Colascione <dancol@google.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Jeff Layton <jlayton@kernel.org>,
linux-fsdevel@vger.kernel.org,
linux-kselftest <linux-kselftest@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
marcandre.lureau@redhat.com,
Mike Kravetz <mike.kravetz@oracle.com>,
Minchan Kim <minchan@kernel.org>, Shuah Khan <shuah@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd
Date: Fri, 19 Oct 2018 14:49:11 -0400 [thread overview]
Message-ID: <118792.1539974951@turing-police.cc.vt.edu> (raw)
In-Reply-To: <CAEXW_YTS2n2tOpXs3eVQZhYu7tmM_at0ZBA-04qYkHw4UE80nw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
> On Fri, Oct 19, 2018 at 10:32 AM, <valdis.kletnieks@vt.edu> wrote:
> > What is supposed to happen if some other process has an already existing R/W
> > mmap of the region? (For that matter, the test program doesn't seem to
> > actually test that the existing mmap region remains writable?)
> Why would it not remain writable? We don't change anything in the
> mapping that prevents it from being writable, in the patch.
OK, if the meaning here is "if another process races and gets its own R/W mmap
before we seal our mmap, it's OK". Seems like somewhat shaky security-wise - a
possibly malicious process can fail to get a R/W map because we just sealed it,
but if it had done the attempt a few milliseconds earlier it would have its own
R/W mmap to do as it pleases...
On the other hand, decades of trying have proven that trying to do any sort
of revoke() is a lot harder to do than it looks...
> We do test that existing writable mmaps can continue to exist after
> the seal is set, in a way, because we test that setting of the seal
> succeeds.
Well, if the semantics are "We don't bother trying to deal with existing R/W
maps", then it doesn't really matter - I was thinking along the lines of "If we're
revoking other R/W accesses, we should test that we didn't nuke *this* one in
the bargain"....
[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu)
Subject: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd
Date: Fri, 19 Oct 2018 14:49:11 -0400 [thread overview]
Message-ID: <118792.1539974951@turing-police.cc.vt.edu> (raw)
In-Reply-To: <CAEXW_YTS2n2tOpXs3eVQZhYu7tmM_at0ZBA-04qYkHw4UE80nw@mail.gmail.com>
On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
> On Fri, Oct 19, 2018 at 10:32 AM, <valdis.kletnieks at vt.edu> wrote:
> > What is supposed to happen if some other process has an already existing R/W
> > mmap of the region? (For that matter, the test program doesn't seem to
> > actually test that the existing mmap region remains writable?)
> Why would it not remain writable? We don't change anything in the
> mapping that prevents it from being writable, in the patch.
OK, if the meaning here is "if another process races and gets its own R/W mmap
before we seal our mmap, it's OK". Seems like somewhat shaky security-wise - a
possibly malicious process can fail to get a R/W map because we just sealed it,
but if it had done the attempt a few milliseconds earlier it would have its own
R/W mmap to do as it pleases...
On the other hand, decades of trying have proven that trying to do any sort
of revoke() is a lot harder to do than it looks...
> We do test that existing writable mmaps can continue to exist after
> the seal is set, in a way, because we test that setting of the seal
> succeeds.
Well, if the semantics are "We don't bother trying to deal with existing R/W
maps", then it doesn't really matter - I was thinking along the lines of "If we're
revoking other R/W accesses, we should test that we didn't nuke *this* one in
the bargain"....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.linaro.org/pipermail/linux-kselftest-mirror/attachments/20181019/49a2b9f1/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: valdis.kletnieks@vt.edu (valdis.kletnieks@vt.edu)
Subject: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd
Date: Fri, 19 Oct 2018 14:49:11 -0400 [thread overview]
Message-ID: <118792.1539974951@turing-police.cc.vt.edu> (raw)
Message-ID: <20181019184911.E2ZNmwH8F-rhOBCFI7zYVZuT69ttmw8EOg0Zerm9arY@z> (raw)
In-Reply-To: <CAEXW_YTS2n2tOpXs3eVQZhYu7tmM_at0ZBA-04qYkHw4UE80nw@mail.gmail.com>
On Fri, 19 Oct 2018 10:57:31 -0700, Joel Fernandes said:
> On Fri, Oct 19, 2018@10:32 AM, <valdis.kletnieks@vt.edu> wrote:
> > What is supposed to happen if some other process has an already existing R/W
> > mmap of the region? (For that matter, the test program doesn't seem to
> > actually test that the existing mmap region remains writable?)
> Why would it not remain writable? We don't change anything in the
> mapping that prevents it from being writable, in the patch.
OK, if the meaning here is "if another process races and gets its own R/W mmap
before we seal our mmap, it's OK". Seems like somewhat shaky security-wise - a
possibly malicious process can fail to get a R/W map because we just sealed it,
but if it had done the attempt a few milliseconds earlier it would have its own
R/W mmap to do as it pleases...
On the other hand, decades of trying have proven that trying to do any sort
of revoke() is a lot harder to do than it looks...
> We do test that existing writable mmaps can continue to exist after
> the seal is set, in a way, because we test that setting of the seal
> succeeds.
Well, if the semantics are "We don't bother trying to deal with existing R/W
maps", then it doesn't really matter - I was thinking along the lines of "If we're
revoking other R/W accesses, we should test that we didn't nuke *this* one in
the bargain"....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.linaro.org/pipermail/linux-kselftest-mirror/attachments/20181019/49a2b9f1/attachment.sig>
next prev parent reply other threads:[~2018-10-19 18:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 6:59 [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd Joel Fernandes (Google)
2018-10-18 6:59 ` Joel Fernandes (Google)
2018-10-18 6:59 ` joel
2018-10-18 6:59 ` [PATCH v3 2/2] selftests/memfd: Add tests for F_SEAL_FS_WRITE seal Joel Fernandes (Google)
2018-10-18 6:59 ` Joel Fernandes (Google)
2018-10-18 6:59 ` joel
2018-10-18 7:08 ` Joel Fernandes
2018-10-18 7:08 ` Joel Fernandes
2018-10-18 7:08 ` joel
2018-10-19 17:32 ` [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd valdis.kletnieks
2018-10-19 17:32 ` valdis.kletnieks
2018-10-19 17:32 ` valdis.kletnieks
2018-10-19 17:57 ` Joel Fernandes
2018-10-19 17:57 ` Joel Fernandes
2018-10-19 17:57 ` joel
2018-10-19 18:49 ` valdis.kletnieks [this message]
2018-10-19 18:49 ` valdis.kletnieks
2018-10-19 18:49 ` valdis.kletnieks
2018-10-19 19:32 ` Joel Fernandes
2018-10-19 19:32 ` Joel Fernandes
2018-10-19 19:32 ` joel
2018-10-22 23:49 ` Joel Fernandes
2018-10-22 23:49 ` Joel Fernandes
2018-10-22 23:49 ` joel
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=118792.1539974951@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=dancol@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jlayton@kernel.org \
--cc=joel@joelfernandes.org \
--cc=john.stultz@linaro.org \
--cc=jreck@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=marcandre.lureau@redhat.com \
--cc=mike.kravetz@oracle.com \
--cc=minchan@kernel.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=tkjos@google.com \
--cc=viro@zeniv.linux.org.uk \
/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.