On Mon, Jul 23, 2012 at 10:36:21PM +0900, sf...@users.sourceforge.net wrote:
>
> Ben Hutchings:
> > If the LSM mmap_addr callback needs to acquire mmap_sem then it will be
> > using the wrong mm context, so this doesn't fix the problem. If it
>
> LSM mmap_addr()? _file()?
Gah, of course I meant mmap_file here!
> If you mean _addr() acquires mmap_sem, then it means a simple problem of
> LSM. Let's make it sure again together. "_addr() is protected by
> mmap_sem". :-)
>
> If you mean _file() (instead of _addr), hmm... it may be possible.
> Thinking over why security_mmap_file() is splitted into _addr() and
> _file(), if I remember correctly, all tasks which requires mmap_sem
> should goes to _addr(), and this is the main reason of splitting.
> But some exotic LSM module may try such breakage (I know we are talking
> on "If ..."). Even such case, I don't think it causes a problem since
> mmap_sem is per task object.
But why would it try to acquire mmap_sem, if not to manipulate the mm
of the task that called mmap()? In which case, it gets the wrong mm.
(Actually, I think current->mm may be NULL for kernel threads. Not
sure whether that's still true.)
> As long as aufs delegates the _file() call
> to kworker, the mmap_sem object which _file() tries to acquire is the
> korker's mmap_sem (instead of the original process).
> I agree with you at the point that the process context differs from the
> original one. But I am not sure how critical it is. In other words, I am
> afraid the _file() call from aufs_mmap() has less meaning, and it is
> just to follow the LSM protocol/manner/rule.
>
>
> > needs to acquire a lock that's higher in the lock hierarchy than
> > mmap_sem then I think an AB-BA deadlock is still possible. Given two
> > threads in the same process:
>
> I think I can understand what you want to point out. Probably the fact
> that "originally _file() doesn't expect to be called with mmap_sem held"
> is the point. And aufs_mmap() tries calling it with faking by another
> thread/mmap_sem.
> But is such higher lock possible? At least, in LSM, it is almost
> impossible (or bad approach). Which hook can do it?
Don't know. But whether or not it happens, I think that the work item
doesn't solve anything.
> > If there is no lock higher than mmap_sem that might be used in this way,
> > then there is no problem and there is also no need for using the
> > workqueue.
>
> ??
> I may be confused again.
> Why workqueue is unnecessary?
The work item runs on *some* workqueue.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
