From: Ursula Braun
Hi Dave,
as requested, here is V3 of the smc-patch with an updated commit log.
V3: update commit log
V2: do not use _internal_mr
V1: switch to usage of IB_PD_UNSAFE_GLOBAL_RKEY
Kind regards, Ursula
Ursula Braun (1):
smc: switch to usage of
From: Ursula Braun
Hi Dave,
yesterday I included a patch proposal into a response to Christoph Hellwig,
which is now already seen here:
http://patchwork.ozlabs.org/patch/761250/
Christoph suggested an additional improvement not to use __internal_mr.
Thus I come up
On Thu, May 11, 2017 at 06:50:04PM +0200, Ursula Braun wrote:
> Please consider the following patch to make users aware of the
> security implications through existing mechanisms.
Any such patch would be in addition to the BROKEN marker until
there is an actual alternative.
> +
On 05/04/2017 10:48 AM, h...@lst.de wrote:
> 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
On Fri, May 05, 2017 at 11:10:17AM -0600, Jason Gunthorpe wrote:
> I recommend immediately sending a kconfig patch cc'd to stable making
> SMC require CONFIG_BROKEN so that nobody inadvertantly turns it on.
Yes, I'll send the patch.
On Fri, May 05, 2017 at 07:06:56PM +0200, Ursula Braun wrote:
> We do not see that just loading the smc module causes this issue.The security
> risk starts with the first connection, that actually uses smc. This is only
> possible if an AF_SMC socket connection is created while the so-called
>
On 05/04/2017 05:31 PM, Jason Gunthorpe wrote:
> On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote:
>>
>>
>> On 05/04/2017 10:48 AM, h...@lst.de wrote:
>>> 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
On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote:
>
>
> On 05/04/2017 10:48 AM, h...@lst.de wrote:
> > 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
On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote:
>
>
> On 05/04/2017 10:48 AM, h...@lst.de wrote:
> > 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
On 05/04/2017 10:48 AM, h...@lst.de wrote:
> 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
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_
if you can point out specific issues, we will be happy to work with you
to get them addressed!
Hello Ursula,
My list of issues that I would like to see addressed can be found below. Doug,
Christoph and others may have additional inputs. The issues that have not yet
been mentioned in other
On 05/02/2017 08:39 PM, Bart Van Assche wrote:
> On Tue, 2017-05-02 at 14:25 +0200, Ursula Braun wrote:
>> if you can point out specific issues, we will be happy to work with you
>> to get them addressed!
>
> Hello Ursula,
>
> My list of issues that I would like to see addressed can be found
On Tue, 2017-05-02 at 14:25 +0200, Ursula Braun wrote:
> if you can point out specific issues, we will be happy to work with you
> to get them addressed!
Hello Ursula,
My list of issues that I would like to see addressed can be found below. Doug,
Christoph and others may have additional inputs.
On Tue, 2017-05-02 at 14:41 +0200, Ursula Braun wrote:
> On 05/01/2017 07:55 PM, Parav Pandit wrote:
> > Hi Bart, Ursula, Dave,
> >
> > I am particularly concerned about SMC as address family.
> > It should not be treated as address family, but rather an additional
> > protocol similar for socket
On 5/2/2017 8:34 AM, Ursula Braun wrote:
> On 05/01/2017 07:29 PM, Bart Van Assche wrote:
>> On Mon, 2017-05-01 at 18:33 +0200, Christoph Hellwig wrote:
>>> Hi Ursual, hi netdev reviewers,
>>>
>>> how did the smc protocol manage to get merged without any review
>>> on linux-rdma at all? As the
gt;> Sent: Monday, May 1, 2017 12:30 PM
>> To: h...@lst.de; da...@davemloft.net; ubr...@linux.vnet.ibm.com
>> Cc: netdev@vger.kernel.org; linux-r...@vger.kernel.org
>> Subject: Re: net/smc and the RDMA core
>>
>> On Mon, 2017-05-01 at 18:33 +0200, Christoph Hellwi
On 05/01/2017 07:29 PM, Bart Van Assche wrote:
> On Mon, 2017-05-01 at 18:33 +0200, Christoph Hellwig wrote:
>> Hi Ursual, hi netdev reviewers,
>>
>> how did the smc protocol manage to get merged without any review
>> on linux-rdma at all? As the results it seems it's very substandard
>> in
On 05/01/2017 06:33 PM, Christoph Hellwig wrote:
> Hi Ursual, hi netdev reviewers,
>
> how did the smc protocol manage to get merged without any review
> on linux-rdma at all? As the results it seems it's very substandard
> in terms of RDMA API usage, e.g. it neither uses the proper CQ API
>
>
> Hi Ursual, hi netdev reviewers,
>
> how did the smc protocol manage to get merged without any review
> on linux-rdma at all? As the results it seems it's very substandard
> in terms of RDMA API usage, e.g. it neither uses the proper CQ API
> nor the RDMA R/W API, and other will probably
Bart Van Assche
> Sent: Monday, May 1, 2017 12:30 PM
> To: h...@lst.de; da...@davemloft.net; ubr...@linux.vnet.ibm.com
> Cc: netdev@vger.kernel.org; linux-r...@vger.kernel.org
> Subject: Re: net/smc and the RDMA core
>
> On Mon, 2017-05-01 at 18:33 +0200, Christoph Hellwig wrot
On Mon, 2017-05-01 at 18:33 +0200, Christoph Hellwig wrote:
> Hi Ursual, hi netdev reviewers,
>
> how did the smc protocol manage to get merged without any review
> on linux-rdma at all? As the results it seems it's very substandard
> in terms of RDMA API usage, e.g. it neither uses the proper
Hi Ursual, hi netdev reviewers,
how did the smc protocol manage to get merged without any review
on linux-rdma at all? As the results it seems it's very substandard
in terms of RDMA API usage, e.g. it neither uses the proper CQ API
nor the RDMA R/W API, and other will probably find additional
23 matches
Mail list logo