[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180304205614.GC23816@bombadil.infradead.org>
Date: Sun, 4 Mar 2018 12:56:14 -0800
From: Matthew Wilcox <willy@...radead.org>
To: Daniel Micay <danielmicay@...il.com>
Cc: Ilya Smith <blackzert@...il.com>, Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>,
Michal Hocko <mhocko@...e.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Jan Kara <jack@...e.cz>, Jerome Glisse <jglisse@...hat.com>,
Hugh Dickins <hughd@...gle.com>, Helge Deller <deller@....de>,
Andrea Arcangeli <aarcange@...hat.com>,
Oleg Nesterov <oleg@...hat.com>, Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [RFC PATCH] Randomization of address chosen by mmap.
On Sat, Mar 03, 2018 at 07:47:04PM -0800, Matthew Wilcox wrote:
> On Sat, Mar 03, 2018 at 04:00:45PM -0500, Daniel Micay wrote:
> > The main thing I'd like to see is just the option to get a guarantee
> > of enforced gaps around mappings, without necessarily even having
> > randomization of the gap size. It's possible to add guard pages in
> > userspace but it adds overhead by doubling the number of system calls
> > to map memory (mmap PROT_NONE region, mprotect the inner portion to
> > PROT_READ|PROT_WRITE) and *everything* using mmap would need to
> > cooperate which is unrealistic.
>
> So something like this?
>
> To use it, OR in PROT_GUARD(n) to the PROT flags of mmap, and it should
> pad the map by n pages. I haven't tested it, so I'm sure it's buggy,
> but it seems like a fairly cheap way to give us padding after every
> mapping.
>
> Running it on an old kernel will result in no padding, so to see if it
> worked or not, try mapping something immediately after it.
Thinking about this more ...
- When you call munmap, if you pass in the same (addr, length) that were
used for mmap, then it should unmap the guard pages as well (that
wasn't part of the patch, so it would have to be added)
- If 'addr' is higher than the mapped address, and length at least
reaches the end of the mapping, then I would expect the guard pages to
"move down" and be after the end of the newly-shortened mapping.
- If 'addr' is higher than the mapped address, and the length doesn't
reach the end of the old mapping, we split the old mapping into two.
I would expect the guard pages to apply to both mappings, insofar as
they'll fit. For an example, suppose we have a five-page mapping with
two guard pages (MMMMMGG), and then we unmap the fourth page. Now we
have a three-page mapping with one guard page followed immediately
by a one-page mapping with two guard pages (MMMGMGG).
I would say that mremap cannot change the number of guard pages.
Although I'm a little tempted to add an mremap flag to permit the mapping
to expand into the guard pages. That would give us a nice way to reserve
address space for a mapping we think is going to expand.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
