All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Peter Collingbourne <pcc@google.com>
Cc: Kostya Kortchinsky <kostyak@google.com>, linux-mm@kvack.org
Subject: Re: [PATCH] mm: improve mprotect(R|W) efficiency on pages referenced once
Date: Wed, 23 Dec 2020 14:34:11 -0800	[thread overview]
Message-ID: <20201223143411.e889bcad32e5a1c0252c745c@linux-foundation.org> (raw)
In-Reply-To: <20201212053152.3783250-1-pcc@google.com>

On Fri, 11 Dec 2020 21:31:52 -0800 Peter Collingbourne <pcc@google.com> wrote:

> In the Scudo memory allocator [1] we would like to be able to
> detect use-after-free vulnerabilities involving large allocations
> by issuing mprotect(PROT_NONE) on the memory region used for the
> allocation when it is deallocated. Later on, after the memory
> region has been "quarantined" for a sufficient period of time we
> would like to be able to use it for another allocation by issuing
> mprotect(PROT_READ|PROT_WRITE).
> 
> Before this patch, after removing the write protection, any writes
> to the memory region would result in page faults and entering
> the copy-on-write code path, even in the usual case where the
> pages are only referenced by a single PTE, harming performance
> unnecessarily. Make it so that any pages in anonymous mappings that
> are only referenced by a single PTE are immediately made writable
> during the mprotect so that we can avoid the page faults.
> 

I worry that some other application out there does a similar thing, but
only expects to very sparsely write to the area.  It will see a big increase
in mprotect() latency.

Would it be better to implement this as a separate operation, rather
than unconditionally tying it into mprotect()?  Say, a new madvise()
operation?


  reply	other threads:[~2020-12-23 22:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12  5:31 [PATCH] mm: improve mprotect(R|W) efficiency on pages referenced once Peter Collingbourne
2020-12-23 22:34 ` Andrew Morton [this message]
2020-12-29  2:09   ` Peter Collingbourne
2020-12-29 19:25     ` Andrew Morton
2020-12-30  0:43       ` Peter Collingbourne

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=20201223143411.e889bcad32e5a1c0252c745c@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=kostyak@google.com \
    --cc=linux-mm@kvack.org \
    --cc=pcc@google.com \
    /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.