[lkml]   [2018]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

 \ /
  Last update: 2018-03-04 21:56    [W:0.059 / U:5.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site