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

Powered by blists - more mailing lists