Timur Tabi <[EMAIL PROTECTED]> 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. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
