netdev - RE: [PATCH net-next 11/18] switchdev: remove old netdev_switch_port_bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Mar 2015 23:32:32 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	Jiri Pirko <jiri@...nulli.us>, Netdev <netdev@...r.kernel.org>
CC:	Scott Feldman <sfeldma@...il.com>,
	roopa <roopa@...ulusnetworks.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Florian Fainelli <f.fainelli@...il.com>
Subject: RE: [PATCH net-next 11/18] switchdev: remove old
 netdev_switch_port_bridge_setlink

>-----Original Message-----
>From: Jiri Pirko [mailto:jiri@...nulli.us]
>Sent: Tuesday, March 31, 2015 2:53 PM
>To: Arad, Ronen
>Cc: Scott Feldman; Netdev; roopa; Guenter Roeck; Florian Fainelli
>Subject: Re: [PATCH net-next 11/18] switchdev: remove old
>netdev_switch_port_bridge_setlink
>
>Tue, Mar 31, 2015 at 09:15:35PM CEST, ronen.arad@...el.com wrote:
>>
>>
>>>-----Original Message-----
>>>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On
>>>Behalf Of Jiri Pirko
>>>Sent: Monday, March 30, 2015 10:53 PM
>>>To: Arad, Ronen
>>>Cc: Scott Feldman; Netdev; roopa; Guenter Roeck; Florian Fainelli
>>>Subject: Re: [PATCH net-next 11/18] switchdev: remove old
>>>netdev_switch_port_bridge_setlink
>>>
>>>Tue, Mar 31, 2015 at 02:08:34AM CEST, ronen.arad@...el.com wrote:
>>>>
[cut]
>>>>
>>>>It could be beneficial to build extensibility into swdev_attr.
>>>>An experimenter attribute designed to carry arbitrary data could allow
>>>>for passing new attributes and implementation specific attributes
>>>>without affecting any existing switchdev driver:
>>>
>>>Warning sign...
>>>
>>>I believe that we don't want this. It is very easy to add attribute for
>>>anything. Having this "universal attribuute" only allows wild things...
>>>
>>>Thanks.
>>>
>>>Jiri
>>>
>>Let's say a switch device has some behavior that is not common to all
>>switch devices. Defining an explicit attribute might not be desirable
>>in that case. For example let's say SOMEswitch device implements VLAN
>>priority markdown using a table. It could be represented as a table of
>>8 bytes. To support this feature, there is a need to allow a user-space
>>tool to program such table in SOMEswitch device. What mechanisms are
>>available for that?
>
>If you want to expose feature X that's ok, just do it. I see no problem
>in that. Please, just do not introduce kernel bypass.

This is not a kernel bypass as long as the target device is an in-tree
device driver open for the community scrutiny. 

 That simply won't
>fly...

Let's say vendor X wants to expose features X1, X2, ...Xm,
vendor Y wants to expose features Y1, Y2, ...Yn, etc.
How this would be visible to the users via iproute2?
We'll need keywords Kx1..Kxm, Ky1..Kn, etc. There is scalability issue here.
The user has to figure out the keyword Kxj goes with feature Xj etc.
There must be a better way.

What I have in mind is a way for switchdevX driver to define the its options
and the keywords that the user could use to control them in a generic way.
The kernel will provide the mechanism to export that to user space such that
A tool like iproute2 could present user-friendly interface which is context
aware. 

It is important to allow for a generic interface that will not require a new
patch to the user-space tool or to the kernel net core (or switchdev) infrastructure, whenever any such new feature is being exposed.
Only the switchdev driver which exposes a new feature need a patch.

The kernel could have sufficient information about the information that
switchdevX is expecting such that it could validate size and type and could
reject information that is not supported by the device.

This is very similar to the options interface the team driver exposes.
Team driver provides the mechanism for user-space to configure options in the
kernel. Team driver does not understand or interpret the options that are
intended for team modes. It only provides the mechanism to communicate them
over generic netlink and process them in the kernel and user-space.
Those options do not show up in any header file. You don't need a new kernel
version to introduce a new team option for a new or existing team mode.
All you need is to register the option (identified by a string) with team
driver and set/get it from the teamd or any other user-space tool over
generic netlink.
The team protocol is stable and does not require changes for this level of
extensibility.

The same level of extensibility is needed for switchdev port or device
attributes.

>
>
>>This could be done via sysfs entries. However, I believe we're trying
>>to make Netlink and iproute2 the protocol/tool for all switch device
>
>It does not matter if universal attr is exposed via netlink or sysfs.
>Either way, I believe it is unacceptable.
>
>>configuration. Therefore, I think that a generic mechanism, integrated
>>with existing switchdev supported tools would be best.
>>Alternative approach would be for SOMEswitch driver to introduce its
>>own generic netlink family and introduce SOMEswitch version of iproute2
>>or similar tool to augment SOMEswitch HW configuration where (or as long
>>as) no common way to control such feature is available
>
>This is definitelly unacceptable :/