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: <1267214397.2098.17.camel@achroite.uk.solarflarecom.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ