linux-kernel - Re: [patch] mm: recheck lock rlim after f

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0707111826530.22786@blonde.wat.veritas.com>
Date:	Wed, 11 Jul 2007 19:03:36 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Christoph Hellwig <hch@...radead.org>
cc:	Jes Sorensen <jes@....com>, Dmitry Monakhov <dmonakhov@...ru>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] mm: recheck lock rlim after f_op->mmap() method

On Wed, 11 Jul 2007, Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 02:12:45PM +0400, Dmitry Monakhov wrote:
> > > > Or would this simpler patch be the right one?  I suspect the
> > > > mspec driver only says VM_LOCKED because of a deep-seated but
> > > > irrational fear that its pages might fall into reclaim.

I was perhaps too unkind: that fear was not irrational in 2.4,
when reclaim scanned vmas; but in 2.6, pages have to be on one
of reclaim's LRUs to fall vulnerable to it.

> > > 
> > > Looks good.  We probably should add a debug check to do_mmap_pgoff
> > > so that ->mmap methods don't change flags that are not for drivers.

We could indeed, though I'd rather not jump into that: something
to do when we tidy up those driver mmaps (something I promised to
do 18 months ago?), there's a lot of pointless flag setting.

> > As result fglrx totally goes crazy, because it change vm_flags
> > even from  ->nopage() calback :)

That must be an exciting new State of the Art version of fglrx.

Looking at what I downloaded for inspection a year ago, I can't
see any sign of that.  But I do see lots of random stabs at setting
different vm_flags in different mmap cases (VM_IO, VM_SHM, VM_RESERVED,
VM_LOCKED): of which the VM_IO serves some point, VM_SHM is defunct,
VM_RESERVED will be defunct, and VM_LOCKED can confuse us.

But interestingly, where they set VM_LOCKED, they did increment
vm_locked: so there shouldn't be that issue of wrapping negative
on munmap, which had worried me.  And now I look at Dmitry's
patch again, I see that he was indeed assuming that the driver
had done that incrementation.

> Well, everyone with half a brain knows that fglrx is not just legally
> problematic but an utter piece of junk.  We should add more debug checks
> to stop it from doing such stupid things.  And yes, chaning flags from
> ->nopage() does not just deserve a warning but a panic.

Well, they'll get what they deserve.  I'm not convinced Dmitry's right
about their nopage; and I'm not going to waste any more time working
out ways to protect ourselves from them.  Let's stick with the mspec.

Hugh
-
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/