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
| ||
|
Message-Id: <1277150272.2100.47.camel@achroite.uk.solarflarecom.com> Date: Mon, 21 Jun 2010 20:57:52 +0100 From: Ben Hutchings <bhutchings@...arflare.com> To: Jeff Kirsher <jeffrey.t.kirsher@...el.com> Cc: jeff@...zik.org, davem@...emloft.net, netdev@...r.kernel.org, gospo@...hat.com, Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com> Subject: Re: [ethtool PATCH] ethtool: Support n-tuple filter programming On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote: > From: Peter Waskiewicz <peter.p.waskiewicz.jr@...el.com> > > Program underlying ethernet devices with n-tuple flow classification > filters. > > This also adds a new flag to ethtool_flags, allowing n-tuple > programming to be toggled using the set_flags call. I just noticed a problem with the implementation which makes me wonder whether this was tested at all: [...] > +static struct cmdline_info cmdline_ntuple[] = { > + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL }, > + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL }, > + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL }, > + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL }, > + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL }, > + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL }, > + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL }, > + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL }, > + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL }, > + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL }, > + { "user-def", CMDL_INT, &ntuple_fs.data, NULL }, > + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL }, > + { "action", CMDL_INT, &ntuple_fs.action, NULL }, > +}; [...] > + if (mode == MODE_SNTUPLE) { > + if (!strcmp(argp[i], "flow-type")) { > + i += 1; > + if (i >= argc) { > + show_usage(1); > + break; > + } > + ntuple_fs.flow_type = > + rxflow_str_to_type(argp[i]); > + i += 1; > + parse_generic_cmdline(argc, argp, i, > + &sntuple_changed, > + cmdline_ntuple, > + ARRAY_SIZE(cmdline_ntuple)); > + i = argc; > + break; > + } else { > + show_usage(1); > + } > + break; > + } [...] parse_generic_cmdline() will write an int for each argument defined with type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some of them are big-endian. I also wonder whether anyone really wants to enter an IPv4 address as a single integer. 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