[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337112446.20904.50.camel@falcor>
Date: Tue, 15 May 2012 16:07:26 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Eric Paris <eparis@...isplace.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Mimi Zohar <zohar@...ibm.com>,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency
On Tue, 2012-05-15 at 15:42 -0400, Eric Paris wrote:
> On Tue, May 15, 2012 at 2:41 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Tue, May 15, 2012 at 10:19 AM, Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> >>
> >> - move the whole call to security_file_mmap() to outside the
> >> mmap_sem, and test the *suggested* address (which is not the same as
> >> the final address)
> >
> > Actually, I think I have a simpler approach.
> >
> > We already actually have two *different* security_file_mmap() calls:
> > it's just that currently the difference is shown by the last argument
> > to the function ("addr_only").
>
> I'm the one who introduced that bit of horrific. I originally did it
> the way you describe and someone (it was a long time ago, and I think
> it was Ted Tso, but I am probably very very wrong on that) ask me to
> tack it on the end like this. I'd be very happy with the split you
> describe.
>
> I'd rather not, however, move the address call site like you described
> above, as I don't want to allow NULL + ~MAP_FIXED to be tested until
> it has been resolved to a real address. I don't want someone to find
> a way to get the kernel to choose 4096 and avoid the check....
If the security_file_mmap() moves to before taking the mmap_sem and the
new security_mmap_addr() hook would be at the current
security_file_mmap() location, I don't see the problem. The addr test
would remain in the same place.
> Mimi, would you like to do this (slightly) larger change? Should I?
np, I'll make the changes.
Mimi
--
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/
Powered by blists - more mailing lists