netdev - Re: [PATCH -next] net: sched: use counter to break reclassify loops

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: <20150513112958.GA6179@breakpoint.cc>
Date:	Wed, 13 May 2015 13:29:58 +0200
From:	Florian Westphal <fw@...len.de>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Florian Westphal <fw@...len.de>, netdev@...r.kernel.org
Subject: Re: [PATCH -next] net: sched: use counter to break reclassify loops

Jamal Hadi Salim <jhs@...atatu.com> wrote:
> On 05/12/15 09:00, Florian Westphal wrote:
> >Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >>Florian,
> >>In general i am in support of removing this - since the use case never
> >>materialized as being useful. However, this is not the same logic that
> >>was there before. To get equivalency you need to pass the limit into
> >>tc_classify_compat() so i can be reset.
> >
> >AFAICS this re-set only happens when we return something other
> >than RECLASSIFY which means the caller will not check the limit.
> >
> >So in fact it should be ok to remove this since the counter will always
> >start from 0 on next tc_classify() invocation.
> >
> 
> Florian, consider the following scenario:
> Assume X is the max allowed reclassified before bells start ringing.
> If we see upto X back-to-back reclassify - we are very much likely in
> a loop. We should see fire trucks arrive and bail out.
> If we see X-1  "reclassify" followed by a "pipe" followed by
> X-1 "reclassify" followed by "ok" then that looks like a healthy
> policy. But that is a a total of 2X-2 reclassifies. You will
> bail out at X reclassifies; what i am saying is you shouldnt.
> And existing logic doesnt. Does that make sense?

Yes, but, if we use your example above then:

tc_classify called
  limit 0
    tc_classify_compat called, ret RECLASSIFY
  limit 1
    tc_classify_compat called, ret RECLASSIFY
  limit 2
    tc_classify_compat called, ret PIPE (== 3)
  tc_classify returns 3
tc_classify called
  limit 0
  ...

So we don't toss skb since any return value other than RECLASSIFY
will make tc_classify() return to its caller, and when caller invokes
tc_classify again the limit variable is set to 0 again.

Does that make sense to you?

Thanks Jamal.
--
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