Re: [RFC v3][PATCH 5/9] Memory managemnet (restore)

[Dave Hansen <dave@linux.vnet.ibm.com>]

On Thu, 2008-09-11 at 03:37 -0400, Oren Laadan wrote:
> Let me start with the bottom line - since this creates too much confusion,
> I'll just switch to the alternative: will use get_user_pages() to bring
> pages in and copy the data directly. Hopefully this will end the discussion.
> 
> (Note, there there is a performance penalty in the form of extra data copy:
> instead of reading data directly to the page, we instead read into a buffer,
> kmap_atomic the page and copy into the page).

Yep but, as we discussed on IRC, this code needs some optimization for
pages in swap, anyway.  It isn't optimal for those, either.  So, for
this we'll leave it at a minimal amount of code rather than maximal
functionality. :)

> > I bugged Serge about this.  He said that this, at least, bypasses the SE
> > Linux checks that are normally done with an mprotect() system call.
> > That's a larger design problem that we need to keep in mind: we need to
> > be careful to keep existing checks in place.
> 
> I also discussed this with Serge, and I got the impression that he
> agreed that there was no security issue because it was all and only
> about private memory.

Yep, as long as there are some sanity checks to make sure that we're not
overriding permissions, I'm happy with this.

> If a task is ptraced, then the tracer can easily arrange for the tracee
> to call mprotect(), or to call sys_restart() with a tampered checkpoint
> file, or do other tricks. The call to mprotect_fix(), on a private vma,
> does not make this any worse. That is why I didn't bother implementing
> that bit.

I completely agree that it isn't an issue on a private VMA.  My only
concern is if this is done to any shared memory or could potentially be
abused in such a way that it gets applied to shared memory.

-- Dave