From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754170Ab2EWVT1 (ORCPT ); Wed, 23 May 2012 17:19:27 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:39301 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754756Ab2EWVTX (ORCPT ); Wed, 23 May 2012 17:19:23 -0400 Message-ID: <1337807899.15138.31.camel@falcor> Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency From: Mimi Zohar To: Al Viro Cc: Linus Torvalds , Eric Paris , Mimi Zohar , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 23 May 2012 17:18:19 -0400 In-Reply-To: <20120516021828.GP22082@ZenIV.linux.org.uk> References: <1336963631-3541-1-git-send-email-zohar@us.ibm.com> <1337112446.20904.50.camel@falcor> <20120516004251.GO22082@ZenIV.linux.org.uk> <20120516021828.GP22082@ZenIV.linux.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 (3.2.3-3.fc16) Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12052321-2398-0000-0000-000006E3D9E8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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