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: <6948a2a9-1ed2-ce8d-daeb-601c425e1258@mojatatu.com>
Date:   Thu, 4 Feb 2021 08:19:55 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Phil Sutter <phil@....cc>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [iproute PATCH] tc: u32: Fix key folding in sample option

Hi Phil,

I couldnt tell by inspection if what used to work before continues to.
In particular the kernel version does consider the divisor when folding.

Two examples that currently work, if you can try them:

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
----

and this i also found in one of my scripts:
----
tc filter add dev $DEV parent 999:0  protocol ip prio 10 u32 \
ht 2:: \
sample u32 0x00000806 0x0000ffff at 12 \
match u32 0x00000800 0x0000ff00 at 12 flowid 1:10 \
action ok
----

Probably a simple meaning of "working" is:
the values before and after (your changes) are consistent.

If also you will do us a kindness and add maybe a testcase in tdc?
This way next person wanting to fix it can run the tests first before
posting a patch.

cheers,
jamal

On 2021-02-02 1:30 p.m., Phil Sutter wrote:
> In between Linux kernel 2.4 and 2.6, key folding for hash tables changed
> in kernel space. When iproute2 dropped support for the older algorithm,
> the wrong code was removed and kernel 2.4 folding method remained in
> place. To get things functional for recent kernels again, restoring the
> old code alone was not sufficient - additional byteorder fixes were
> needed.
> 
> While being at it, make use of ffs() and thereby align the code with how
> kernel determines the shift width.
> 
> Fixes: 267480f55383c ("Backout the 2.4 utsname hash patch.")
> Signed-off-by: Phil Sutter <phil@....cc>
> ---
> Initially I considered changing the kernel's key folding instead as the
> old method didn't just ignore key bits beyond the first byte. Yet I am
> not sure if this would cause problems with hardware offloading. And
> given the fact that this simplified key folding is in place since the
> dawn of 2.6, it is probably not such a big problem anyway.
> ---
>   tc/f_u32.c | 11 ++++++++---
>   1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/tc/f_u32.c b/tc/f_u32.c
> index 2ed5254a40d5f..a5747f671e1ea 100644
> --- a/tc/f_u32.c
> +++ b/tc/f_u32.c
> @@ -978,6 +978,13 @@ show_k:
>   	goto show_k;
>   }
>   
> +static __u32 u32_hash_fold(struct tc_u32_key *key)
> +{
> +	__u8 fshift = key->mask ? ffs(ntohl(key->mask)) - 1 : 0;
> +
> +	return ntohl(key->val & key->mask) >> fshift;
> +}
> +
>   static int u32_parse_opt(struct filter_util *qu, char *handle,
>   			 int argc, char **argv, struct nlmsghdr *n)
>   {
> @@ -1110,9 +1117,7 @@ static int u32_parse_opt(struct filter_util *qu, char *handle,
>   				}
>   				NEXT_ARG();
>   			}
> -			hash = sel2.keys[0].val & sel2.keys[0].mask;
> -			hash ^= hash >> 16;
> -			hash ^= hash >> 8;
> +			hash = u32_hash_fold(&sel2.keys[0]);
>   			htid = ((hash % divisor) << 12) | (htid & 0xFFF00000);
>   			sample_ok = 1;
>   			continue;
>