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: <20150122151316.GB25797@casper.infradead.org>
Date:	Thu, 22 Jan 2015 15:13:16 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Pablo Neira Ayuso <pablo@...filter.org>,
	John Fastabend <john.fastabend@...il.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/15 at 10:00am, Jamal Hadi Salim wrote:
> On 01/22/15 09:00, Pablo Neira Ayuso wrote:
> 
> >
> >+/* rocker specific action definitions */
> >+struct net_flow_action_arg rocker_set_group_id_args[] = {
> >+       {
> >+               .name = "group_id",
> >+               .type = NFL_ACTION_ARG_TYPE_U32,
> >+               .value_u32 = 0,
> >+       },
> >
> >that is retrieved via ndo_flow_get_actions and fully exposed to
> >userspace.
> >
> 
> My main concern is along similar lines (I did express it earlier and
> I think Jiri chimed in as well).
> The API exposes direct access to hardware. I am sure this was a result
> of trying to replace the ethtool interface (which was primitive).
> By providing vendors direct access to the hardware - they do not need
> to use any traditional Linux tooling/APIs.

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.

Pablo raises an interesting point though. How do we handle unique
features like Rocker groups.

Maybe Jiri and Scott can chime in and describe if we can map this to
something more generic and avoid exporting anything Rocker specific.

What would a rocker group map to in the tc world?

> I see this as a gaping hole
> for vendor SDKs with their own definitions of their own hardware that
> doesnt work with anyone else. i.e it seems to standardize proprietary
> interfaces. Maybe thats what Pablo is alluding to.

I will be the first to root for rejection if such patches appear.
--
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