From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 24 May 2006 16:10:08 +0100 (BST) From: Hugh Dickins Subject: Re: tracking dirty pages patches In-Reply-To: <1148437514.3049.18.camel@laptopd505.fenrus.org> Message-ID: References: <1148437514.3049.18.camel@laptopd505.fenrus.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Arjan van de Ven Cc: linux-mm@kvack.org, Rohit Seth , David Howells , Linus Torvalds , Andrew Morton , Peter Zijlstra , Christoph Lameter List-ID: 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: email@kvack.org