Trust model for raw QPs

Trust model for raw QPs

[Or Gerlitz]

Currently, for an app to open a raw QP from user space, we (verbs) 
require admin permission, for which we (Mellanox) got customer feedback 
saying this is problematic on some of the environments.

Suppose we allow to user to provide source mac+vlan when creating the QP 
or when modifying its state, and the HW can enforce that -- in that case 
I think its OK to remove that restriction e.g ala what is allowed today 
with user space UD QPs when the fabric is IB.

Or.
--
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

Re: Trust model for raw QPs

[Steve Wise]

On 8/15/2012 8:28 AM, Or Gerlitz wrote:
> Currently, for an app to open a raw QP from user space, we (verbs) 
> require admin permission, for which we (Mellanox) got customer 
> feedback saying this is problematic on some of the environments.
>
> Suppose we allow to user to provide source mac+vlan when creating the 
> QP or when modifying its state, and the HW can enforce that -- in that 
> case I think its OK to remove that restriction e.g ala what is allowed 
> today with user space UD QPs when the fabric is IB.
>
> Or.

We have similar requirements from customers.   I don't understand how 
mac+vlan allows the driver to enforce anything?  Can you explain this 
further?

Stevo

--
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

Re: Trust model for raw QPs

[Or Gerlitz]

On 15/08/2012 16:40, Steve Wise wrote:
> On 8/15/2012 8:28 AM, Or Gerlitz wrote:
>> Currently, for an app to open a raw QP from user space, we (verbs) 
>> require admin permission, for which we (Mellanox) got customer 
>> feedback saying this is problematic on some of the environments.
>>
>> Suppose we allow to user to provide source mac+vlan when creating the 
>> QP or when modifying its state, and the HW can enforce that -- in 
>> that case I think its OK to remove that restriction e.g ala what is 
>> allowed today with user space UD QPs when the fabric is IB.
>>
> We have similar requirements from customers.   I don't understand how 
> mac+vlan allows the driver to enforce anything?  Can you explain this 
> further?

Its what's  called HW anti spoofing support, very common in the 
virtualization world when you want te HW to enforce source mac/vlan for 
Ethernet frames sent by a VM using an SRIOV VF -- user-space is a 
private case of that very same problem. Its not driver enforcement, its 
driver advertizing the ability of the HW to enforce.

Or.

--
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

Re: Trust model for raw QPs

[Christoph Lameter]

On Wed, 15 Aug 2012, Or Gerlitz wrote:

> Currently, for an app to open a raw QP from user space, we (verbs) require
> admin permission, for which we (Mellanox) got customer feedback saying this is
> problematic on some of the environments.

Well yes it is but the kernel mod is a one line to get rid of this
problem.

> Suppose we allow to user to provide source mac+vlan when creating the QP or
> when modifying its state, and the HW can enforce that -- in that case I think
> its OK to remove that restriction e.g ala what is allowed today with user
> space UD QPs when the fabric is IB.

Well yes that would mean that the source mac and vlan are configured with
admin permissions and then the app would run without within the
constraints established in priviledged moded.


--
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

Re: Trust model for raw QPs

[Or Gerlitz]

On 15/08/2012 17:06, Christoph Lameter wrote:
> On Wed, 15 Aug 2012, Or Gerlitz wrote:
>
>> Currently, for an app to open a raw QP from user space, we (verbs) require
>> admin permission, for which we (Mellanox) got customer feedback saying this is
>> problematic on some of the environments.
>
> Well yes it is but the kernel mod is a one line to get rid of this problem.

Its one LOC that has behind it many lines  of reasoning... e.g as 
specified in the change-log, those QP are to some extent the RDMA stack 
form of packet/raw sockets.

>
>
>> Suppose we allow to user to provide source mac+vlan when creating the QP or when modifying its state, and the HW can enforce that -- in that case I think its OK to remove that restriction e.g ala what is allowed today with user space UD QPs when the fabric is IB.
>
> Well yes that would mean that the source mac and vlan are configured with
> admin permissions and then the app would run without within the
> constraints established in priviledged moded.

There a co-existence between the IP stack and the RDMA stack, which is 
for example exercised by the RDMA-CM design, here also, the admin 
configured a MAC and VLAN for a netdevice that is bounded to a HW 
NIC/port we want to create RAW QP on, and there's a non privileged user 
space app that want to  generate frames with this mac/vlan, and we say 
its allowed once the HW can enforce that.

Or.


--
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

Re: Trust model for raw QPs

[Jason Gunthorpe]

On Wed, Aug 15, 2012 at 04:28:38PM +0300, Or Gerlitz wrote:

> Suppose we allow to user to provide source mac+vlan when creating
> the QP or when modifying its state, and the HW can enforce that --
> in that case I think its OK to remove that restriction e.g ala what
> is allowed today with user space UD QPs when the fabric is IB.

This is still not safe, letting userspace inject raw ethernet packets,
even with a set smac and vlan tag will still allow it to disrupt TCP
communications, send privileged ICMPs, send packets from privileged
ports, etc.

UD QPs have an enforced SQPN, which AFAIK, is very different from how
raw ethernet QPs work. To fix it properly you'd have to make them less
'raw', enforce a certain eth/IPv4/TCP/UDP header stack on rx and tx,
for instance.

Not sure about receive? What packets do the raw QPs receive? That
needs to be pretty narrow too.

Can you fix this by elevating the process with SELinux?

Jason
--
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

Re: Trust model for raw QPs

[Or Gerlitz]

Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:

> Can you fix this by elevating the process with SELinux?

Chirstoph, do you think this would valid option from users standpoint?

Or.
--
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

Re: Trust model for raw QPs

[Christoph Lameter]

On Wed, 15 Aug 2012, Or Gerlitz wrote:

> Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
>
> > Can you fix this by elevating the process with SELinux?
>
> Chirstoph, do you think this would valid option from users standpoint?

Sure. If SELinux can be used to compromise systems security (in a
controlled fashion) then I think we finally found a reason to use the
stuff. Could someone explain how this would work? Hopefully this is easily
usable and controllable?

--
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

Re: Trust model for raw QPs

[Christoph Lameter]

On Wed, 15 Aug 2012, Jason Gunthorpe wrote:

> Can you fix this by elevating the process with SELinux?

Can SELinux be used to compromise security? How?

--
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

Re: Trust model for raw QPs

[Jason Gunthorpe]

On Wed, Aug 15, 2012 at 05:33:10PM +0000, Christoph Lameter wrote:
> On Wed, 15 Aug 2012, Jason Gunthorpe wrote:
> 
> > Can you fix this by elevating the process with SELinux?
> 
> Can SELinux be used to compromise security? How?

Not 100% familiar with SELinux, but they do support ping and other
tools which do operate with elevated priviliages, so it must be
possible.

A how-to document on this subject and a dedicated SELinux capability
might be the way to go..

Jason
--
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