netdev - Re: [patch net-next v3 1/9] ipv4: fib_rules: Check if rule is a default rule

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: <24ac2262-c47d-3540-b28f-dba612f76f76@cumulusnetworks.com>
Date:   Thu, 16 Mar 2017 09:18:30 -0600
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, idosch@...lanox.com, mlxsw@...lanox.com,
        shm@...ulusnetworks.com, kuznet@....inr.ac.ru, jmorris@...ei.org,
        yoshfuji@...ux-ipv6.org, kaber@...sh.net, lorenzo@...gle.com,
        mateusz.bajorski@...ia.com
Subject: Re: [patch net-next v3 1/9] ipv4: fib_rules: Check if rule is a
 default rule

On 3/16/17 2:08 AM, Jiri Pirko wrote:
> From: Ido Schimmel <idosch@...lanox.com>
> 
> Currently, when non-default (custom) FIB rules are used, devices capable
> of layer 3 offloading flush their tables and let the kernel do the
> forwarding instead.
> 
> When these devices' drivers are loaded they register to the FIB
> notification chain, which lets them know about the existence of any
> custom FIB rules. This is done by sending a RULE_ADD notification based
> on the value of 'net->ipv4.fib_has_custom_rules'.
> 
> This approach is problematic when VRF offload is taken into account, as
> upon the creation of the first VRF netdev, a l3mdev rule is programmed
> to direct skbs to the VRF's table.
> 
> Instead of merely reading the above value and sending a single RULE_ADD
> notification, we should iterate over all the FIB rules and send a
> detailed notification for each, thereby allowing offloading drivers to
> sanitize the rules they don't support and potentially flush their
> tables.
> 
> While l3mdev rules are uniquely marked, the default rules are not.
> Therefore, when they are being notified they might invoke offloading
> drivers to unnecessarily flush their tables.
> 
> Solve this by adding an helper to check if a FIB rule is a default rule.
> Namely, its selector should match all packets and its action should
> point to the local, main or default tables.
> 
> As noted by David Ahern, uniquely marking the default rules is
> insufficient. When using VRFs, it's common to avoid false hits by moving
> the rule for the local table to just before the main table:
> 
> Default configuration:
> $ ip rule show
> 0:      from all lookup local
> 32766:  from all lookup main
> 32767:  from all lookup default
> 
> Common configuration with VRFs:
> $ ip rule show
> 1000:   from all lookup [l3mdev-table]
> 32765:  from all lookup local
> 32766:  from all lookup main
> 32767:  from all lookup default
> 
> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
> ---
>  include/net/fib_rules.h |  1 +
>  include/net/ip_fib.h    |  7 +++++++
>  net/core/fib_rules.c    | 14 ++++++++++++++
>  net/ipv4/fib_rules.c    | 21 +++++++++++++++++++++
>  4 files changed, 43 insertions(+)
> 

Acked-by: David Ahern <dsa@...ulusnetworks.com>