linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jann Horn <jannh@google.com>
Cc: Topi Miettinen <toiwoton@gmail.com>,
	linux-hardening@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND v2] mm: Optional full ASLR for mmap() and mremap()
Date: Thu, 8 Oct 2020 18:41:22 +0100	[thread overview]
Message-ID: <20201008174122.GM20115@casper.infradead.org> (raw)
In-Reply-To: <CAG48ez3-uvDXL7-WBapEJMHrkXYpnAw=AgbP2evOZgNMFWKy-A@mail.gmail.com>

On Thu, Oct 08, 2020 at 07:26:31PM +0200, Jann Horn wrote:
> On Thu, Oct 8, 2020 at 7:23 PM Matthew Wilcox <willy@infradead.org> wrote:
> > On Thu, Oct 08, 2020 at 07:13:51PM +0200, Jann Horn wrote:
> > > And for expanding stacks, it might be a good idea for other
> > > reasons as well (locking consistency) to refactor them such that the
> > > size in the VMA tree corresponds to the maximum expansion of the stack
> > > (and if an allocation is about to fail, shrink such stack mappings).
> >
> > We're doing that as part of the B-tree ;-)  Although not the shrink
> > stack mappings part ...
> 
> Wheee, thanks! Finally no more data races on ->vm_start?

Ah, maybe still that.  The B-tree records the start of the mapping in
the tree, but we still keep vma->vm_start as pointing to the current top
of the stack (it's still the top if it grows down ... right?)  The key is
that these numbers may now be different, so from the tree's point of view,
the vm addresses for 1MB below the stack appear to be occupied.  From the
VMA's point of view, the stack finishes where it was last accessed.

We also get rid of the insanity of "return the next VMA if there's no
VMA at this address" which most of the callers don't want and have to
check for.  Again, from the tree's point of view, there is a VMA at this
address, but from the VMA's point of view, it'll need to expand to reach
that address.

I don't think this piece is implemented yet, but it's definitely planned.


  reply	other threads:[~2020-10-08 17:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 16:54 [PATCH RESEND v2] mm: Optional full ASLR for mmap() and mremap() Topi Miettinen
2020-10-08 17:07 ` Matthew Wilcox
2020-10-08 18:11   ` Topi Miettinen
2020-10-08 17:13 ` Jann Horn
2020-10-08 17:23   ` Matthew Wilcox
2020-10-08 17:26     ` Jann Horn
2020-10-08 17:41       ` Matthew Wilcox [this message]
2020-10-08 18:10   ` Topi Miettinen
2020-10-08 18:24     ` Jann Horn

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=20201008174122.GM20115@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=toiwoton@gmail.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 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).