netdev - Re: [net-next PATCH v3 00/12] Flow API

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]

Message-ID: <54C12EFB.3000004@gmail.com>
Date:	Thu, 22 Jan 2015 09:10:19 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Pablo Neira Ayuso <pablo@...filter.org>
CC:	Thomas Graf <tgraf@...g.ch>, Jamal Hadi Salim <jhs@...atatu.com>,
	simon.horman@...ronome.com, sfeldma@...il.com,
	netdev@...r.kernel.org, davem@...emloft.net, gerlitz.or@...il.com,
	andy@...yhouse.net, ast@...mgrid.com, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [net-next PATCH v3 00/12] Flow API

On 01/22/2015 08:49 AM, Pablo Neira Ayuso wrote:
> On Thu, Jan 22, 2015 at 03:37:27PM +0000, Thomas Graf wrote:
>> On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
>>> On 01/22/15 10:13, Thomas Graf wrote:
>>>
>>>> I don't follow this. John's proposal allows to decide on a case by
>>>> case basis what we want to export. Just like with ethtool or
>>>> RTNETLINK. There is no direct access to hardware. A user can only
>>>> configure what is being exposed by the kernel.
>>>>
>>>
>>> So if i am a vendor with my own driver, I can expose whatever i want.
>>
>> No. We will reject any driver change attempting to do so on this
>> list.
>
> I think those vendors do not want to push those driver changes
> mainstream. They will likely use these new ndo's to fully expose their
> vendor-specific capabilities distributed in proprietary blobs.
>
> I remember to have seen one ugly patch for netfilter that added
> several hook functions (not netfilter hooks) at different positions of
> the NAT code, the goal was to offload NAT through hardware. I was told
> the code that was using those ad-hoc hooks was distributed in a binary
> blob.
>
>> This is the whole point of this: Coming up with a model that allows
>> to describe capabilities and offer flow programming capabilities
>> in a Vendor neutral way. A "push_vlan" or "pop_vlan" action will work
>> with any driver that supports it.
>
> Right, we need an abstraction for actions too, and the infrastructure
> should not provide any means to circunvent and expose vendor specific
> details.
>

I'm not sure what a vendor specific detail is in the API now?

The API provides a mechanism to define the headers you support in a
vendor neutral way. Perhaps vendor X may be the only hardware to
support the packet type but the packets are not really vendor specific
if we have the packet layout we can generate code to create the packets
if we care to in software and find it useful.

Maybe the issue is the actions look like UIDs without any specification
as to what they do? The concern being as a vendor I could create an
action and call it my_vendor_specific_action and if I never tell anyone
how to use it then we are stuck.

I can add a set of specifier attributes to the get_action call that
describes actions using basic primitives to resolve this specific issue.
Actions should either 'set' fields, 'get' fields, 'dec' fields, 'inc'
fields, etc. Then you specify an action by providing the list of
operations it performs. So set_group_id is simply

	'set_field uid=group_id_metadata'

More complicated actions exist like route() and such which will be a
list of operations that may set multiple fields in a single atomic step.

The table API also seems vendor neutral to me. I'm not sure what
specific details would be vendor specific here either.

.John

-- 
John Fastabend         Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html