netdev - Re: "Forwarding" from TC classifier

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:   Fri, 15 May 2020 08:24:39 -0600
From:   David Ahern <dsahern@...il.com>
To:     Lorenz Bauer <lmb@...udflare.com>
Cc:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Martynas Pumputis <m@...bda.lt>,
        kernel-team <kernel-team@...udflare.com>
Subject: Re: "Forwarding" from TC classifier

On 5/15/20 3:59 AM, Lorenz Bauer wrote:
> 
> Yes, but that doesn't play well with changing the source address to
> the local machine's, since the upper part of the stack will drop the
> packet due to accept_local=0.

Can you defer the source address swap to the Tx path? Let the packet go
up the stack and do the fib lookup again as an skb. neighbor entry does
not exist, so the packet is stashed, neighbor resolution done, once
resolved the packet goes out. tc program on the egress device can flip
the source address, and then subsequent packets take the XDP fast path.

If the next host is on the same LAN I believe the stack will want to
generate an ICMP redirect, but that can be squashed.