Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Andrew Morton]

Timur Tabi <timur.tabi@xxxxxxxxxxx> wrote:
>
> Andrew Morton wrote:
> 
> > 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.
> 
> I don't see what's wrong with relying on userspace to call mlock().  First all, all RDMA 
> apps call a third-party API, like DAPL or MPI, to register memory.  The memory needs to be 
> registered in order for the driver and adapter to know where it is.  During this 
> registration, the memory is also pinned.  That's when we call mlock().

All the above refers to well-behaved applications.

Now think about how the syscalls which you provide may be used by
applications which are *designed* to cripple or to compromise the machine.

> > 
> > However an hostile app can just go and run munlock() and then allocate
> > some more pinned-by-get_user_pages() memory.
> 
> Isn't mlock() on a per-process basis anyway?  How can one process call munlock() on 
> another process' memory?

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.

> > 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
> 
> Isn't this kinda what mlock() does already?  Create a new VMA and then VM_LOCK it?

kinda.  But applications can undo the mlock which the kernel did.

> > 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?
> 
> Yes, but do_mlock() needs to prevent pages from being moved during memory hotswap.

I haven't even thought about memory hotswap.  Surely it'll fail if the
pages are pinned by get_user_pages()?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/