Messages in this thread |  | | | Date | Mon, 25 Apr 2005 21:33:15 -0700 | | From | Andrew Morton <> | | Subject | Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation |
| |
Timur Tabi <timur.tabi@ammasso.com> wrote: > > Andrew Morton wrote: > > > I'm referring to an application which uses your syscalls to obtain pinned > > memory and uses munlock() so that it may then use your syscalls to obtain > > evem more pinned memory. With the objective of taking the machine down. > > I'm in favor of having drivers call do_mlock() and do_munlock() on behalf of the > application. All we need to do is export those functions, and my driver can call them. > However, that still doesn't prevent an app from calling munlock().
Precisely. That's why I suggested that we have an alternative vma->vm_flag bit which behaves in a similar manner to VM_LOCKED (say, VM_LOCKED_KERNEL), only userspace cannot alter it.
> But I don't understand the distinction between having the driver call do_mlock() vs. the > application calling mlock(). Won't we still have the same problems? A malicious app can > just call our driver instead of calling mlock() or munlock(). The driver won't know the > difference between an authorized app and an unauthorized one.
The driver will set VM_LOCKED_KERNEL, not VM_LOCKED.
> Besides, isn't the whole point behind RLIMIT_MEMLOCK to limit how much one process can lock?
Sure. The internal setting of VM_LOCKED_KERNEL should still use RLIMIT_MEMLOCK accounting.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |