netdev - Re: [iproute PATCH] tc: u32: Fix key folding in sample option

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: <20210204145006.GT3158@orbyte.nwl.cc>
Date:   Thu, 4 Feb 2021 15:50:06 +0100
From:   Phil Sutter <phil@....cc>
To:     Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Subject: Re: [iproute PATCH] tc: u32: Fix key folding in sample option

On Thu, Feb 04, 2021 at 09:34:01AM -0500, Jamal Hadi Salim wrote:
> On 2021-02-04 9:04 a.m., Phil Sutter wrote:
> > Jamal,
> > 
> > On Thu, Feb 04, 2021 at 08:19:55AM -0500, Jamal Hadi Salim wrote:
> >> I couldnt tell by inspection if what used to work before continues to.
> >> In particular the kernel version does consider the divisor when folding.
> > 
> > That's correct. And so does tc. What's the matter?
> > 
> 
> tc assumes 256 when undefined. Maybe man page needs to be
> updated to state we need divisor specified otherwise default
> is 256.

tc-u32.8 mentions the default in 'sample' option description. Specifying
divisor is mandatory when creating a hash table, so that path is
covered, too. I still don't get how this is related to my patch, though.

> >> Two examples that currently work, if you can try them:
> > 
> > Both lack information about the used hashkey and divisor.
> > 
> >> Most used scheme:
> >> ---
> >> tc filter add dev $DEV parent 999:0  protocol ip prio 10 u32 \
> >> ht 2:: \
> >> sample ip protocol 1 0xff match ip src 1.2.3.4/32 flowid 1:10 \
> >> action ok
> >> ----
> > 
> > htid before: 0x201000
> > htid after: 0x201000
> > 
> 
> Ok, this is the most common use-case. So we are good.

Whatever.

Thanks, Phil