Re: [PATCH] vfs: fix IMA lockdep circular locking dependency

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Wed, 2012-05-16 at 03:18 +0100, Al Viro wrote:
> On Tue, May 15, 2012 at 05:45:44PM -0700, Linus Torvalds wrote:
> > On Tue, May 15, 2012 at 5:42 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >

> Frankly, I would split it in two - one introducing security_mmap_addr()
> and converting the callers, and another doing the rest of it.

Ok, I split the patch. Hopefully it is bisect safe. The results of which
are available from
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
#next-vfs-changes.  But before posting them, I'd like to understand what
should be done regarding the issues you raised.

> Said that, I'm not sure I like the resulting picture.
> 
> 1) caller in __bprm_mm_init() is simply ridiculous - note that
> arguments are bleeding *constants*, so it might very well have
> been a BUG_ON().  If it fails, you'll have every execve() fail.

ok, checking the addr based on the same constants doesn't make sense.
Replace it with a BUG_ON() as you suggested?

> 2) get_unmapped_area() probably ought to grow such a caller and
> I really suspect that it would've killed quite a few of them.

?

> 3) expand_downwards() seems to be missing the basic sanity checks on the
> validity of VMA range (arch_mmap_check(), that is).  itanic opencodes
> the equivalent before calling expand_stack(); arm and mn10300 do not
> bother, which might or might not be legitimate - depends on whether
> one can get a fault in the first page *and* reach the check_stack:
> in e.g. arm __do_page_fault().  Which just might be possible, if attacker
> maps something just above said first page with MAP_GROWSDOWN and
> tries to write at very small address - IIRC, the first page on arm
> contains the stuff that shouldn't be world-writable...  s390 doesn't
> care and I'm not sure about sparc32/sparc64 - it looks like that shouldn't
> be possible to hit, but...

?

> 4) i810_dma.c ought to be switched to vm_mmap() - as discussed in that
> thread back then, magical mystery wank with ->f_op reassignments does
> not rely on ->mmap_sem for protection and thus can be taken out of
> under ->mmap_sem.

Ok, replacing the do_mmap() with vm_mmap() would be a separate patch,
but it still leaves the existing f_op reassignment with locking issues.

thanks,

Mimi