Messages in this thread | | | Date | Mon, 25 Apr 2005 17:37:57 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation |
| |
Roland Dreier <roland@topspin.com> wrote: > > Andrew> How does the driver detect process exit? > > I already answered earlier but just to be clear: registration goes > through a character device, and all regions are cleaned up in the > ->release() of that device.
yup.
> I don't currently have any code accounting against RLIMIT_MEMLOCK or > testing CAP_FOO, but I have no problem adding whatever is thought > appropriate. Userspace also has control over the permissions and > owner/group of the /dev node.
I guess device node permissions won't be appropriate here, if only because it sounds like everyone will go and set them to 0666.
RLIMIT_MEMLOCK sounds like the appropriate mechanism. We cannot rely upon userspace running mlock(), so perhaps it is appropriate to run sys_mlock() in-kernel because that gives us the appropriate RLIMIT_MEMLOCK checking.
However an hostile app can just go and run munlock() and then allocate some more pinned-by-get_user_pages() memory.
umm, how about we
- force the special pages into a separate vma
- run get_user_pages() against it all
- use RLIMIT_MEMLOCK accounting to check whether the user is allowed to do this thing
- undo the RMLIMIT_MEMLOCK accounting in ->release
This will all interact with user-initiated mlock/munlock in messy ways. Maybe a new kernel-internal vma->vm_flag which works like VM_LOCKED but is unaffected by mlock/munlock activity is needed.
A bit of generalisation in do_mlock() should suit? - 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/
| |