linux-kernel - Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Oct 2018 10:57:31 -0700
From:   Joel Fernandes <joel@...lfernandes.org>
To:     valdis.kletnieks@...edu
Cc:     LKML <linux-kernel@...r.kernel.org>,
        kernel-team <kernel-team@...roid.com>,
        John Reck <jreck@...gle.com>,
        John Stultz <john.stultz@...aro.org>,
        Todd Kjos <tkjos@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Daniel Colascione <dancol@...gle.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Jeff Layton <jlayton@...nel.org>,
        linux-fsdevel@...r.kernel.org,
        linux-kselftest <linux-kselftest@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, marcandre.lureau@...hat.com,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Minchan Kim <minchan@...nel.org>,
        Shuah Khan <shuah@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 1/2] mm: Add an F_SEAL_FUTURE_WRITE seal to memfd

On Fri, Oct 19, 2018 at 10:32 AM,  <valdis.kletnieks@...edu> wrote:
> On Wed, 17 Oct 2018 23:59:07 -0700, "Joel Fernandes (Google)" said:
>> This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
>> To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal
>> which prevents any future mmap and write syscalls from succeeding while
>> keeping the existing mmap active. The following program shows the seal
>> working in action:
>
> 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.

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.

I could test that processor stores can continue to happen my doing a
memset into the existing map, but I feel that is like testing 2+2 = 4,
in a way ;-) Do you really think its worth testing? If you do, then I
could add a test for that.

- Joel