| Message ID | 1548768386-28289-1-git-send-email-joeln@il.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | RDMA: reg_remote_mr | expand |
On 1/29/2019 7:26 AM, Joel Nider wrote: > As discussed at LPC'18, there is a need to be able to register a memory > region (MR) on behalf of another process. One example is the case of > post-copy container migration, in which CRIU is responsible for setting > up the migration, but the contents of the memory are from the migrating > process. In this case, we want all RDMA READ requests to be served by > the address space of the migration process directly (not by CRIU). This > patchset implements a new uverbs command which allows an application to > register a memory region in the address space of another process. Hey Joel, Dumb question: Doesn't this open a security hole by allowing any process to register memory in any other process? Steve.
On Tue, Jan 29, 2019 at 10:44:48AM -0600, Steve Wise wrote: > > On 1/29/2019 7:26 AM, Joel Nider wrote: > > As discussed at LPC'18, there is a need to be able to register a memory > > region (MR) on behalf of another process. One example is the case of > > post-copy container migration, in which CRIU is responsible for setting > > up the migration, but the contents of the memory are from the migrating > > process. In this case, we want all RDMA READ requests to be served by > > the address space of the migration process directly (not by CRIU). This > > patchset implements a new uverbs command which allows an application to > > register a memory region in the address space of another process. > > Hey Joel, > > Dumb question: > > Doesn't this open a security hole by allowing any process to register > memory in any other process? I agree, Changing all MR to use FOLL_REMOTE seems wrong. Ira > > Steve. > >
Steve Wise <swise@opengridcomputing.com> wrote on 01/29/2019 06:44:48 PM: > > On 1/29/2019 7:26 AM, Joel Nider wrote: > > As discussed at LPC'18, there is a need to be able to register a memory > > region (MR) on behalf of another process. One example is the case of > > post-copy container migration, in which CRIU is responsible for setting > > up the migration, but the contents of the memory are from the migrating > > process. In this case, we want all RDMA READ requests to be served by > > the address space of the migration process directly (not by CRIU). This > > patchset implements a new uverbs command which allows an application to > > register a memory region in the address space of another process. > > Hey Joel, > > Dumb question: > > Doesn't this open a security hole by allowing any process to register > memory in any other process? Not a dumb question - there is a security problem. Jason just suggested I look at how ptrace solves the problem, so that's my best option at the moment. Still, I figured it was a good idea to let everyone take a look at what I have so far, and start to get feedback. > Steve. > >