linux-kernel - Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

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:   Tue, 18 Feb 2020 18:05:58 -0700
From:   David Ahern <dsahern@...il.com>
To:     Carmine Scarpitta <carmine.scarpitta@...roma2.it>
Cc:     davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, ahmed.abdelsalam@...i.it,
        dav.lebrun@...il.com, andrea.mayer@...roma2.it,
        paolo.lungaroni@...t.it
Subject: Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

On 2/18/20 4:50 PM, Carmine Scarpitta wrote:
> Indeed both call fib_table_lookup and rt_dst_alloc are exported for modules. 
> However, several functions defined in route.c are not exported:
> - the two functions rt_cache_valid and rt_cache_route required to handle the routing cache
> - find_exception, required to support fib exceptions.
> This would require duplicating a lot of the IPv4 routing code. 
> The reason behind this change is really to reuse the IPv4 routing code instead of doing a duplication. 
> 
> For the fi member of the struct fib_result, we will fix it by initializing before "if (!tbl_known)"

The route.c code does not need to know about the fib table or fib
policy. Why do all of the existing policy options (mark, L3 domains,
uid) to direct the lookup to the table of interest not work for this use
case?