On 7/9/2015 6:53 PM, Jason Gunthorpe wrote:
On Thu, Jul 09, 2015 at 06:18:26PM -0400, Doug Ledford wrote:
A lot of this discussion is interesting and has gone off in an area that
I think is worth pursuing in the long run. However, in the short run,
this patch was a minor cleanup/simplification patch. These discussions
are moving into complete redesigns and rearchitecting. Steve, I'm OK
with the cleanup and would prefer that it stay separate from these
larger issues.
So, I was originally of the view the flags change was fine.
But when I realized that it basically hides a
ib_get_dma_mr(IB_ACCESS_REMOTE_WRITE) behind an opaque API:
rdma_get_dma_mr(RDMA_MRR_READ_DEST)
I changed my mind.
Yes, I agree. Creating a writable privileged rmr for the RDMA Read sink
buffer exposes all of physical memory to a simple arithmetic mistake.
This should never be allowed in a production config.
That said, for the use by the NFS/RDMA Server, the risk is significantly
mitigated. The sink MR is never sent to the peer by the NFS upper layer,
it is protected by the connection's PD, and it is enabled only when the
RDMA Read is active. However, the very real risk remains. This should
definitely not be the standard API.
For iWarp the above creates a rkey that can RDMA WRITE to any place in
system memory. If a remote guesses that rkey your system is totally
compromised. So it is insecure, and contrary to the advice in RFC5042.
Seeing rdma_get_dma_mr(RDMA_MRR_READ_DEST) added all over the code
base terrifies me, because it is utterly wrong, and looks harmless.
The mistep, is that enabling iSER for iWarp is not just this trivial
change:
- device->mr = ib_get_dma_mr(device->pd, IB_ACCESS_LOCAL_WRITE);
+ mr_roles = RDMA_MRR_RECV | RDMA_MRR_SEND | RDMA_MRR_WRITE_SOURCE |
+ RDMA_MRR_READ_DEST;
+ device->mr = rdma_get_dma_mr(device->pd, mr_roles, 0);
Yep. It's the only safe, correct solution.
> But, it must also follow the path of NFS and use FRMR on iWarp for
> RDMA READ lkeys. This is the real quirk of iWarp, not that the MR
> flags are slightly different.
>
From there, it is a logical wish: If Steve is going to FRMR'ize iSER
to be acceptable security wise, I'd rather see that work done on in a
general way. Hence the API discussion.
Well, it's important to realize that NFS already does the Right Thing.
So it isn't actually an urgent issue. There is time to discuss.
Tom.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
