Re: tracking dirty pages patches

[Hugh Dickins <hugh@veritas.com>]

On Wed, 24 May 2006, Arjan van de Ven wrote:
> On Tue, 2006-05-23 at 21:34 +0100, Hugh Dickins wrote:
> 
> > You mentioned in one of the mails that went past that you'd seen
> > drivers enforcing VM_LOCKED in vm_flags: aren't those just drivers
> > copying other drivers which did so, but achieving nothing thereby,
> > to be cleaned up in due course?  (The pages aren't even on LRU.)
> 
> I would like to know which, because in general this is a security hole:
> Any driver that depends on locked meaning "doesn't move" can be fooled
> by the user into becoming unlocked... (by virtue of having another
> thread do an munlock on the memory). As such no kernel driver should 
> depend on this, and as far as I know, no kernel driver actually does.

You'll have seen the list in Christoph's patch.  But they're all
remap_pfn_range users, largely copied one from another, and their
pages won't become freeable even if the user munlocks.

However, that munlocking will lower locked_vm when it shouldn't
touch it.  I suppose the ingenious might mmap and munmap such a
driver in order to lock another mapping beyond RLIMIT_MEMLOCK.
Perhaps that raises the priority of Christoph's patch?

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>