netdev - Re: [RFC v2 bpf-next 0/9] bpf: Add helper to do FIB lookups

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: <20180501.102036.1322546431945930447.davem@davemloft.net>
Date:   Tue, 01 May 2018 10:20:36 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...il.com
Cc:     netdev@...r.kernel.org, borkmann@...earbox.net, ast@...nel.org,
        shm@...ulusnetworks.com, roopa@...ulusnetworks.com,
        brouer@...hat.com, toke@...e.dk, john.fastabend@...il.com
Subject: Re: [RFC v2 bpf-next 0/9] bpf: Add helper to do FIB lookups

From: David Ahern <dsahern@...il.com>
Date: Sun, 29 Apr 2018 11:07:43 -0700

> Provide a helper for doing a FIB and neighbor lookups in the kernel
> tables from an XDP program. The helper provides a fastpath for forwarding
> packets. If the packet is a local delivery or for any reason is not a
> simple lookup and forward, the packet is expected to continue up the stack
> for full processing.
> 
> Patches 1-6 do some more refactoring to IPv6 with the end goal of
> extracting a FIB lookup function that aligns with fib_lookup for IPv4,
> basically returning a fib6_info without creating a dst based entry.
> 
> Patch 7 adds lookup functions to the ipv6 stub. These are needed since
> bpf is built into the kernel and ipv6 may not be built or loaded.
> 
> Patch 8 adds the bpf helper and 9 adds a sample program.
> 
> v2
> - fixed use of foward helper from cls_act as noted by Daniel
> - in patch 1 rename fib6_lookup_1 as well for consistency

I've reviewed this and generally I agree with the semantic choices
wrt. resolution.

We really can't do neigh resolution without an SKB, so at least in
the xdp case we must push the packet up into the full stack path.

I guess we could do the neigh resolve in the cls_bpf case, but I
wonder how helpful that would be.