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, 28 Apr 2017 15:11:56 +0200
From:   Simon Horman <simon.horman@...ronome.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Jiri Pirko <jiri@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Dinan Gunawardena <dinan.gunawardena@...ronome.com>,
        netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [PATCH/RFC net-next 0/4] net/sched: cls_flower: avoid false
 matching of truncated packets

On Fri, Apr 28, 2017 at 08:52:56AM -0400, Jamal Hadi Salim wrote:
> On 17-04-28 08:00 AM, Simon Horman wrote:
> >Hi,
> >
> >this series is intended to avoid false-positives which match
> >truncated packets against flower classifiers which match on:
> >* zero L4 ports or;
> >* zero ICMP code or type
> >
> >This requires updating the flow dissector to return an error in such cases
> >and updating flower to not match on the result of a failed dissection.
> >
> >In the case of UDP this results in a behavioural change to users of
> >flow_keys_dissector_keys[] and flow_keys_dissector_symmetric_keys[] -
> >dissection will fail on truncated packets where the IP protocol of the
> >packets indicates ports should be present (according to skb_flow_get_ports()).
> 
> I think i understand the use case/need.
> But would it be fair to say that the truncated vs non-truncated are two
> different filter rules?

How would you describe such a rule? The case that is being dealt with is
one where there is a parse error and thus nothing to match on from a flower
pov.

> Example what would offloading of
> header_parse_err_action mean?

Why would it need to differ semantically to the implementation in this
patch? I feel that I am missing something.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ