On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote:
I would also suggest that you stop exposing the DMA MR for remote
access (at least by default) and use a proper reg_mr operations with a
limited lifetime on a properly sized buffer.
Yes, exposing the default DMA MR is a _major_ security risk. As soon
as SMC is enabled this will mean a remote system has full read/write
access to the local systems memory.
There іs a reason why I removed the ib_get_dma_mr function and replaced
it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name
and a very long comment explaining why, and I'm really disappointed that
we got a driver merged that instead of asking on the relevant list on
why a change unexpertong a function it needed happened and instead
tried the hard way to keep a security vulnerarbility alive.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/04/2017 10:48 AM, hch@lst.de wrote:
On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote:
quoted
I would also suggest that you stop exposing the DMA MR for remote
access (at least by default) and use a proper reg_mr operations with a
limited lifetime on a properly sized buffer.
Yes, exposing the default DMA MR is a _major_ security risk. As soon
as SMC is enabled this will mean a remote system has full read/write
access to the local systems memory.
There іs a reason why I removed the ib_get_dma_mr function and replaced
it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name
and a very long comment explaining why, and I'm really disappointed that
we got a driver merged that instead of asking on the relevant list on
why a change unexpertong a function it needed happened and instead
tried the hard way to keep a security vulnerarbility alive.
Thanks for pointing out these problems. We will address them.
On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote:
On 05/04/2017 10:48 AM, hch@lst.de wrote:
quoted
On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote:
quoted
I would also suggest that you stop exposing the DMA MR for remote
access (at least by default) and use a proper reg_mr operations with a
limited lifetime on a properly sized buffer.
Yes, exposing the default DMA MR is a _major_ security risk. As soon
as SMC is enabled this will mean a remote system has full read/write
access to the local systems memory.
There ??s a reason why I removed the ib_get_dma_mr function and replaced
it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name
and a very long comment explaining why, and I'm really disappointed that
we got a driver merged that instead of asking on the relevant list on
why a change unexpertong a function it needed happened and instead
tried the hard way to keep a security vulnerarbility alive.
Thanks for pointing out these problems. We will address them.
So, you've created a huge security hole in the kernel, anyone who
loads your smc module is vunerable.
What are you going to do *RIGHT NOW* to mitigate this?
Jason