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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1221237288.17910.26.camel@nimitz>
Date:	Fri, 12 Sep 2008 09:34:48 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Oren Laadan <orenl@...columbia.edu>
Cc:	containers@...ts.linux-foundation.org, jeremy@...p.org,
	arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [RFC v3][PATCH 5/9] Memory managemnet (restore)

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/