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]

Date:	Thu, 22 Jan 2015 17:44:45 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Pablo Neira Ayuso <pablo@...filter.org>
Cc:	Jamal Hadi Salim <jhs@...atatu.com>,
	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 05:49pm, 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.

You can achieve the exact same thing with an out of tree tc action,
classifier or even a new link type. Nothing prevents an out of tree
driver to register a new rtnetlink link type and do vendor specific
crap.

Out of tree code can abuse any kernel API in any way it wants. Not
sure how much we can do about that.

That said, as we know, vendor specific SDKs for most of the chips in
question here already exist. I'm not sure why a vendor would want to
use this infrastructure (which is subject to constant internal API
changes) to implement vendor specific APIs if that vendor already has
an indepdendent out of tree SDK.
--
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