RDMA fixes for 4.15

PATCH New Leon Romanovsky 10 participants 21 messages Nov 21, 2017 – Nov 22, 2017 10 messages not in the archive

Subsystems (2)

Stable branch InfiniBand

lore

Share & tools

lore

Leon Romanovsky

author

2017-11-21 10:26 UTC #0 lore raw

cover RDMA fixes for 4.15

There are two fixes, one from Daniel fixes iWARP regression caused by SELinux patches and another from Moni to create PSN according to IBTA specification.

The patches are available in the git repository at:
git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git tags/rdma-rc-2017-11-21

Thanks
---------------------------------------

Daniel Jurgens (1):
IB/core: Only enforce security for InfiniBand

Moni Shoua (1):
RDMA/cma: Make sure that PSN is not over max allowed

 drivers/infiniband/core/cma.c      | 1 +
 drivers/infiniband/core/security.c | 9 +++++++++
 2 files changed, 10 insertions(+)

Signature · 6 lines

2.15.0

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Leon Romanovsky

2017-11-21 10:26 UTC #1 lore raw

PATCH 1/2 IB/core: Only enforce security for InfiniBand

From: Daniel Jurgens <[email protected]>

For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL.

Cc Paul Moore <[email protected]>

Cc Don Dutile <[email protected]>

Cc [email protected]

Reported-by Potnuri Bharat Teja <[email protected]>

Fixes d291f1a65232("IB/core: Enforce PKey security on QPs")

Fixes 47a2b338fe63("IB/core: Enforce security on management datagrams")

Signed-off-by Daniel Jurgens <[email protected]>

Reviewed-by Parav Pandit <[email protected]>

Tested-by Potnuri Bharat Teja <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

---
 drivers/infiniband/core/security.c | 9 +++++++++
 1 file changed, 9 insertions(+)

drivers/infiniband/core/security.c +9 -0

index 23278ed5be45..314bf1137c7b 100644
@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
 
 int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
 {
+	u8 i = rdma_start_port(dev);
+	bool is_ib = false;
 	int ret;
 
+	while (i <= rdma_end_port(dev) && !is_ib)
+		is_ib = rdma_protocol_ib(dev, i++);
+
+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;
+
 	qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
 	if (!qp->qp_sec)
 		return -ENOMEM;

Signature · 1 line

2.15.0

Mark Bloch

2017-11-21 10:44 UTC #2 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Hi,

Quoted 26 lines · Leon Romanovsky

From: Daniel Jurgens <[email protected]>
For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL.
Cc Paul Moore <[email protected]>
Cc Don Dutile <[email protected]>
Cc [email protected]
Reported-by Potnuri Bharat Teja <[email protected]>
Fixes d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by Daniel Jurgens <[email protected]>
Reviewed-by Parav Pandit <[email protected]>
Tested-by Potnuri Bharat Teja <[email protected]>
Signed-off-by Leon Romanovsky <[email protected]>
---
 drivers/infiniband/core/security.c | 9 +++++++++
 1 file changed, 9 insertions(+)
drivers/infiniband/core/security.c +0 -0
index 23278ed5be45..314bf1137c7b 100644

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 426

Quoted 10 lines

drivers/infiniband/core/security.c +5 -0

@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
 
 int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
 {
+	u8 i = rdma_start_port(dev);
+	bool is_ib = false;
 	int ret;
 
+	while (i <= rdma_end_port(dev) && !is_ib)
+		is_ib = rdma_protocol_ib(dev, i++);
+

What happens if we have mixed port types?
I believe mlx4 can expose two ports where each port uses a different ll protocol. Was that changed?

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 433

Quoted 8 lines

drivers/infiniband/core/security.c +4 -0

+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;
+
 	qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
 	if (!qp->qp_sec)
 		return -ENOMEM;

Mark.

Leon Romanovsky

2017-11-21 13:22 UTC #3 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 36 lines · Mark Bloch

Hi,
Quoted 33 lines · Leon Romanovsky
From: Daniel Jurgens <[email protected]>
For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL.
Cc Paul Moore <[email protected]>
Cc Don Dutile <[email protected]>
Cc [email protected]
Reported-by Potnuri Bharat Teja <[email protected]>
Fixes d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by Daniel Jurgens <[email protected]>
Reviewed-by Parav Pandit <[email protected]>
Tested-by Potnuri Bharat Teja <[email protected]>
Signed-off-by Leon Romanovsky <[email protected]>
---
 drivers/infiniband/core/security.c | 9 +++++++++
 1 file changed, 9 insertions(+)
drivers/infiniband/core/security.c +2 -0
index 23278ed5be45..314bf1137c7b 100644
@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
 
 int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
 {
+	u8 i = rdma_start_port(dev);
+	bool is_ib = false;
 	int ret;
 

Quoted 5 lines

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 426
Quoted 3 lines
drivers/infiniband/core/security.c +3 -0
+	while (i <= rdma_end_port(dev) && !is_ib)
+		is_ib = rdma_protocol_ib(dev, i++);
+
What happens if we have mixed port types?

We will have is_ib set and qp_sec will be allocated on device layer and not on port level, but because pkeys are IB specific term (at least, I didn't find any mentioning in RoCE spec), the modify_qp won't query for PKEYS.

Quoted 2 lines

I believe mlx4 can expose two ports where each port uses a different ll protocol. Was that changed?

It is still true.

Quoted 15 lines

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 433
Quoted 9 lines
drivers/infiniband/core/security.c +4 -0
+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;
+
 	qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
 	if (!qp->qp_sec)
 		return -ENOMEM;
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20171121132215.GU18825-U/[email protected]

Mark Bloch

2017-11-21 13:56 UTC #5 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 43 lines · Leon Romanovsky

Quoted 36 lines · Mark Bloch
Hi,
Quoted 33 lines · Leon Romanovsky
From: Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL.
Cc Paul Moore <[email protected]>
Cc Don Dutile <[email protected]>
Cc [email protected]
Reported-by Potnuri Bharat Teja <[email protected]>
Fixes d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
Reviewed-by Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>
Tested-by Potnuri Bharat Teja <[email protected]>
Signed-off-by Leon Romanovsky <[email protected]>
---
 drivers/infiniband/core/security.c | 9 +++++++++
 1 file changed, 9 insertions(+)
drivers/infiniband/core/security.c +2 -0
index 23278ed5be45..314bf1137c7b 100644
@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
 
 int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
 {
+	u8 i = rdma_start_port(dev);
+	bool is_ib = false;
 	int ret;
 
Quoted 5 lines
drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 426
Quoted 3 lines
drivers/infiniband/core/security.c +3 -0
+	while (i <= rdma_end_port(dev) && !is_ib)
+		is_ib = rdma_protocol_ib(dev, i++);
+
What happens if we have mixed port types?

Quoted 5 lines

We will have is_ib set and qp_sec will be allocated on device layer and not on port level, but because pkeys are IB specific term (at least, I didn't find any mentioning in RoCE spec), the modify_qp won't query for PKEYS.

What is port level for qp_sec?

I just gave mlx4 as an example, but I was talking more about the ability of the RDMA subsystem to support mixed port types, so in this case, if in the future a vendor will come with an ib_device with 2 ports, one is IB and one is iWARP bad things will happen.

Quoted 20 lines

Quoted 2 lines
I believe mlx4 can expose two ports where each port uses a different ll protocol. Was that changed?
It is still true.
Quoted 15 lines
drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 433
Quoted 9 lines
drivers/infiniband/core/security.c +4 -0
+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;
+
 	qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
 	if (!qp->qp_sec)
 		return -ENOMEM;
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Jason Gunthorpe

2017-11-21 15:14 UTC #6 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 3 lines · Mark Bloch

I just gave mlx4 as an example, but I was talking more about the ability of the RDMA subsystem to support mixed port types, so in this case, if in the future a vendor will come with an ib_device with 2 ports, one is IB and one is iWARP bad things will happen.

That will never be allowed.

Even mixing roce and IB on the same device should be banned, IMHO.

If APM does not work between the ports then they do not belong on the same device.

Jason

Mark Bloch

2017-11-21 15:33 UTC #7 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 8 lines · Jason Gunthorpe

Quoted 3 lines · Mark Bloch
I just gave mlx4 as an example, but I was talking more about the ability of the RDMA subsystem to support mixed port types, so in this case, if in the future a vendor will come with an ib_device with 2 ports, one is IB and one is iWARP bad things will happen.
That will never be allowed.

You say never be allowed, I say code talks, and in the code we don't have this restriction. maybe we should add something?

LSM security enforcement should only take place on IB devices, Daniel's comment even says that:

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 429

Quoted 3 lines

drivers/infiniband/core/security.c +3 -0

+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;

but how do we define an ib device with different port types?
also while today we only deal with pkeys (if I remember currently) in the future we might add other bits, and those bits might not play nicely in the that configuration.

Maybe we should make sure all the ports are IB, and if not, flag it to the user (dmesg?)

Quoted 7 lines

Even mixing roce and IB on the same device should be banned, IMHO.
If APM does not work between the ports then they do not belong on the same device.
Jason

Mark.

Jason Gunthorpe

2017-11-21 15:36 UTC #8 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 2 lines · Mark Bloch

You say never be allowed, I say code talks, and in the code we don't have this restriction. maybe we should add something?

I say that because I will NAK any attempt to merge such a driver.

I'd welcome patches to encforce this restriction in the core.

Quoted 2 lines

Maybe we should make sure all the ports are IB, and if not, flag it to the user (dmesg?)

I would welcome this patch too.

Will this break any mellanox drivers?

Jason

A message that is not in the archive (sent off-list or not yet received): 3eff140b-8f0f-1c4f-07b7-9dec46090a1e-VPRAkNaXOzVWk0Htik3J/[email protected]

Daniel Jurgens

2017-11-21 15:37 UTC #10 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 14 lines · Mark Bloch

Quoted 7 lines · Jason Gunthorpe
Quoted 3 lines · Mark Bloch
I just gave mlx4 as an example, but I was talking more about the ability of the RDMA subsystem to support mixed port types, so in this case, if in the future a vendor will come with an ib_device with 2 ports, one is IB and one is iWARP bad things will happen.
That will never be allowed.
You say never be allowed, I say code talks, and in the code we don't have this restriction. maybe we should add something?
LSM security enforcement should only take place on IB devices, Daniel's comment even says that:

Quoted 8 lines

Review
Quoted 3 lines
(quoted diff) +3 -0
+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;
but how do we define an ib device with different port types?
also while today we only deal with pkeys (if I remember currently) in the future we might add other bits, and those bits might not play nicely in the that configuration.
Maybe we should make sure all the ports are IB, and if not, flag it to the user (dmesg?)

The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.

Quoted 8 lines

Quoted 7 lines
Even mixing roce and IB on the same device should be banned, IMHO. If APM does not work between the ports then they do not belong on the same device.
Jason
Mark.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 410e7b54-02f5-849c-e3ad-56cc61f66647-VPRAkNaXOzVWk0Htik3J/[email protected]

Jason Gunthorpe

2017-11-21 16:04 UTC #12 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 3 lines · Daniel Jurgens

The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.

I would really like to see cx3 be changed to not do that, then we could finalize this issue upstream: All device ports must be the same protocol.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20171121160442.GB18272-uk2M96/[email protected]

Leon Romanovsky

author

2017-11-21 16:34 UTC #14 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 9 lines · Jason Gunthorpe

Quoted 3 lines · Daniel Jurgens
The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.
I would really like to see cx3 be changed to not do that, then we could finalize this issue upstream: All device ports must be the same protocol.

I don't see the point of such artificial limitation, the users who brought CX-3 have option to work in mixed mode and IMHO it is not right to deprecate such ability just because it is hard for us to code for it.

Thanks

Quoted 2 lines

Jason

Jason Gunthorpe

2017-11-21 16:36 UTC #15 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 7 lines · Leon Romanovsky

Quoted 6 lines · Jason Gunthorpe
Quoted 3 lines · Daniel Jurgens
The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.

Quoted 7 lines

Quoted 3 lines
I would really like to see cx3 be changed to not do that, then we could finalize this issue upstream: All device ports must be the same protocol.
I don't see the point of such artificial limitation, the users who brought CX-3 have option to work in mixed mode and IMHO it is not right to deprecate such ability just because it is hard for us to code for it.

I don't really think it is really too user visible.. Only the device and port number change, but only if running in mixed mode.

It is not just 'hard for us' it is impossible to reconcile the differences between ports when enforcing device level things.

This keeps coming up again and again..

Jason

A message that is not in the archive (sent off-list or not yet received): 20171121163648.GC18272-uk2M96/[email protected]

Leon Romanovsky

author

2017-11-21 16:48 UTC #17 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 12 lines · Jason Gunthorpe

Quoted 11 lines · Leon Romanovsky
Quoted 9 lines · Jason Gunthorpe
Quoted 3 lines · Daniel Jurgens
The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.
I would really like to see cx3 be changed to not do that, then we could finalize this issue upstream: All device ports must be the same protocol.

Quoted 6 lines

Quoted 3 lines
I don't see the point of such artificial limitation, the users who brought CX-3 have option to work in mixed mode and IMHO it is not right to deprecate such ability just because it is hard for us to code for it.
I don't really think it is really too user visible.. Only the device and port number change, but only if running in mixed mode.

Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices to two devices once it is configured in mixed mode, so everyone will have one port only. Did I understand you correctly?

Quoted 7 lines

It is not just 'hard for us' it is impossible to reconcile the differences between ports when enforcing device level things.
This keeps coming up again and again..
Jason

A message that is not in the archive (sent off-list or not yet received): 20171121164802.GY18825-U/[email protected]

Jason Gunthorpe

2017-11-21 17:10 UTC #19 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 5 lines · Leon Romanovsky

On Tue, Nov 21, 2017 at 09:36:48AM -0700, Jason Gunthorpe wrote:
Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices to two devices once it is configured in mixed mode, so everyone will have one port only. Did I understand you correctly?

Right, but only for mixed mode. dual port roce or dual port ib is not altered.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Don Dutile

2017-11-21 18:16 UTC #20 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

In reply to Leon Romanovsky

Quoted 17 lines · Leon Romanovsky

Quoted 16 lines · Jason Gunthorpe
Quoted 14 lines · Leon Romanovsky
Quoted 9 lines · Jason Gunthorpe
Quoted 3 lines · Daniel Jurgens
The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.
I would really like to see cx3 be changed to not do that, then we could finalize this issue upstream: All device ports must be the same protocol.
I don't see the point of such artificial limitation, the users who brought CX-3 have option to work in mixed mode and IMHO it is not right to deprecate such ability just because it is hard for us to code for it.

Quoted 7 lines

Quoted 2 lines
I don't really think it is really too user visible.. Only the device and port number change, but only if running in mixed mode.
Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices to two devices once it is configured in mixed mode, so everyone will have one port only. Did I understand you correctly?

Which would require splitting resources that are shared now? other splitting issue(s)?

Quoted 7 lines

Quoted 7 lines
It is not just 'hard for us' it is impossible to reconcile the differences between ports when enforcing device level things.
This keeps coming up again and again..
Jason

Jason Gunthorpe

2017-11-21 18:57 UTC #21 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 9 lines · Don Dutile

Quoted 6 lines
Quoted 2 lines
I don't really think it is really too user visible.. Only the device and port number change, but only if running in mixed mode.
Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices to two devices once it is configured in mixed mode, so everyone will have one port only. Did I understand you correctly?
Which would require splitting resources that are shared now? other splitting issue(s)?

A change like this would be almost transparent to most users. The cx3 card in mixed mode will look like a mlx5 card does: two single port RDMA devices.

I think only a minimal amount of stuff is actually shared between ports, and as cx5 already demonstrates there isn't really a notable downside to having two kernel RDMA devices.

Jason

Leon Romanovsky

2017-11-21 20:40 UTC #22 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 12 lines · Jason Gunthorpe

Quoted 9 lines · Don Dutile
Quoted 6 lines
Quoted 2 lines
I don't really think it is really too user visible.. Only the device and port number change, but only if running in mixed mode.
Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices to two devices once it is configured in mixed mode, so everyone will have one port only. Did I understand you correctly?
Which would require splitting resources that are shared now? other splitting issue(s)?

Quoted 7 lines

A change like this would be almost transparent to most users. The cx3 card in mixed mode will look like a mlx5 card does: two single port RDMA devices.
I think only a minimal amount of stuff is actually shared between ports, and as cx5 already demonstrates there isn't really a notable downside to having two kernel RDMA devices.

CX4+ cards have completely different HW architecture in opposite to CX3, and mlx5 implementation doesn't mean that your suggestion is doable for mlx4. It worth to check it.

Thanks

Quoted 2 lines

Jason

A message that is not in the archive (sent off-list or not yet received): 20171121163454.GW18825-U/[email protected]

Don Dutile

2017-11-21 18:15 UTC #24 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 7 lines · Leon Romanovsky

Quoted 6 lines · Jason Gunthorpe
Quoted 3 lines · Daniel Jurgens
The only warning that would make sense is if the mixed ports aren't all IB or RoCE. As you note, CX-3 can mix those two, we don't want to see warnings about that.

Quoted 8 lines

Quoted 3 lines
I would really like to see cx3 be changed to not do that, then we could finalize this issue upstream: All device ports must be the same protocol.
I don't see the point of such artificial limitation, the users who brought CX-3 have option to work in mixed mode and IMHO it is not right to deprecate such ability just because it is hard for us to code for it.

We use cx-3 (& cx-4 & cx-5) in mixed mode all over our RDMA cluster. Loosing that feature is not an option.

Quoted 4 lines

Thanks
Quoted 2 lines
Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 4f5268b5-e5b6-a7d9-2096-70b4ae8facaf-VPRAkNaXOzVWk0Htik3J/[email protected]

Daniel Jurgens

2017-11-21 13:56 UTC #26 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 36 lines · Mark Bloch

Hi,
Quoted 33 lines · Leon Romanovsky
From: Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL.
Cc Paul Moore <[email protected]>
Cc Don Dutile <[email protected]>
Cc [email protected]
Reported-by Potnuri Bharat Teja <[email protected]>
Fixes d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
Reviewed-by Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>
Tested-by Potnuri Bharat Teja <[email protected]>
Signed-off-by Leon Romanovsky <[email protected]>
---
 drivers/infiniband/core/security.c | 9 +++++++++
 1 file changed, 9 insertions(+)
drivers/infiniband/core/security.c +2 -0
index 23278ed5be45..314bf1137c7b 100644
@@ -417,8 +417,17 @@ void ib_close_shared_qp_security(struct ib_qp_security *sec)
 
 int ib_create_qp_security(struct ib_qp *qp, struct ib_device *dev)
 {
+	u8 i = rdma_start_port(dev);
+	bool is_ib = false;
 	int ret;
 

Quoted 6 lines

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 426
Quoted 3 lines
drivers/infiniband/core/security.c +3 -0
+	while (i <= rdma_end_port(dev) && !is_ib)
+		is_ib = rdma_protocol_ib(dev, i++);
+
What happens if we have mixed port types?
I believe mlx4 can expose two ports where each port uses a different ll protocol. Was that changed?

If any port on the device is IB security is enforced on all QPs because a QP could eventually be modified to an IB port. The primary motivation was to fix a regression in iWARP, which has no concept of PKeys, queries of the PKey cache always returned -EINVAL. There is a valid PKey cache for RoCE, so it's doesn't suffer the same issue, but this will benefit an all RoCE port device by eliminating the overhead of security enforcement. If there is ever a multiport device that mixes iWARP and IB this would be a problem, but I don't see that happening.

Quoted 10 lines

drivers/infiniband/core/security.c void ib_close_shared_qp_security(struct ib_qp_security *sec) · line 433
Quoted 9 lines
drivers/infiniband/core/security.c +4 -0
+	/* If this isn't an IB device don't create the security context */
+	if (!is_ib)
+		return 0;
+
 	qp->qp_sec = kzalloc(sizeof(*qp->qp_sec), GFP_KERNEL);
 	if (!qp->qp_sec)
 		return -ENOMEM;
Mark.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): 20171121102618.31216-2-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

Leon Romanovsky

author

2017-11-22 16:49 UTC #28 lore raw

Re: [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

Quoted 17 lines · Leon Romanovsky

From: Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
For now the only LSM security enforcement mechanism available is specific to InfiniBand. Bypass enforcement for non-IB link types. This fixes a regression where modify_qp fails for iWARP because querying the PKEY returns -EINVAL.
Cc Paul Moore <[email protected]>
Cc Don Dutile <[email protected]>
Cc [email protected]
Reported-by Potnuri Bharat Teja <[email protected]>
Fixes d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>
Reviewed-by Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>
Tested-by Potnuri Bharat Teja <[email protected]>
Signed-off-by Leon Romanovsky <[email protected]>

Quoted 3 lines

---
 drivers/infiniband/core/security.c | 9 +++++++++
 1 file changed, 9 insertions(+)

Please drop this patch, I mistakenly cut it. It doesn't contain the whole fix now, I'll respin.

Thanks

A message that is not in the archive (sent off-list or not yet received): 20171121102618.31216-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org

Leon Romanovsky

author

2017-11-21 10:26 UTC #30 lore raw

PATCH 2/2 RDMA/cma: Make sure that PSN is not over max allowed

From: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch limits the initial value for PSN to 24 bits as spec requires.

Cc Sean Hefty <[email protected]>

Fixes e51060f08a61 ("IB: IP address based RDMA connection manager")

Signed-off-by Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/[email protected]>

Signed-off-by Mukesh Kacker <[email protected]>

Signed-off-by Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/[email protected]>

Reviewed-by Parav Pandit <parav-VPRAkNaXOzVWk0Htik3J/[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

---
 drivers/infiniband/core/cma.c | 1 +
 1 file changed, 1 insertion(+)

drivers/infiniband/core/cma.c +1 -0

index 1fdb473b5df7..f6983357145d 100644
@@ -801,6 +801,7 @@ struct rdma_cm_id *rdma_create_id(struct net *net,
 	INIT_LIST_HEAD(&id_priv->mc_list);
 	get_random_bytes(&id_priv->seq_num, sizeof id_priv->seq_num);
 	id_priv->id.route.addr.dev_addr.net = get_net(net);
+	id_priv->seq_num &= 0x00ffffff;
 
 	return &id_priv->id;
 }

--
2.15.0

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html