netdev - Re: [ethtool PATCH] ethtool: Support n-tuple filter programming

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:	Fri, 26 Feb 2010 19:59:57 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	davem@...emloft.net,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: Re: [ethtool PATCH] ethtool: Support n-tuple filter programming

On Thu, 2010-02-25 at 21:26 -0500, Jeff Garzik wrote:
> On 02/25/2010 08:49 PM, Waskiewicz Jr, Peter P wrote:
[...]
> > This will require a small kernel change.  Will something like this be
> > pulled in at this point, given that 2.6.33 just released?
> 
> The n-tuple stuff is not in 2.6.33's ethtool interface, so it hasn't 
> actually made it into a released kernel at this point.
> 
> It seems reasonable for 2.6.34 to either add ETHTOOL_GSTRINGS_COUNT or 
> update drvinfo.  Even if net-next has already been pulled into 
> post-2.6.33 merge window, that would IMO qualify as a reasonable 
> interface bugfix to get upstream.  The ethtool n-tuple ABI is not locked 
> into stone until 2.6.34 is released by Linus.

Given that, I would really like to see the tuple strings replaced with
binary structures.  Setting them in binary format and retrieving them in
text format is inelegant.  Also we should not assume that ethtool is the
only user of the ethtool API.  If someone wanted to write a GUI to
manage the filter tuples, or a tool that would programmatically
reconfigure filters, they would have to parse the strings.

Even the lookup of number of strings seems to be completely
misconceived.  It's delegated to the driver thus:

        ret = ops->get_sset_count(dev, gstrings.string_set);
        if (ret < 0)
                return ret;

What if gstrings.string_set != ETH_SS_NTUPLE_FILTERS?  Why is that even
a parameter to the operation?

Further, each filter can be formatted as multiple strings.  So is the
driver supposed to know how many strings the ethtool core might
generate?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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