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
| ||
|
Message-ID: <87ednz9rxn.fsf@laptop.lockywolf.net> Date: Tue, 02 May 2023 13:50:38 +0800 From: Vladimir Nikishkin <vladimir@...ishkin.pw> To: Stephen Hemminger <stephen@...workplumber.org> Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, eng.alaamohamedsoliman.am@...il.com, gnault@...hat.com, razor@...ckwall.org, idosch@...dia.com, liuhangbin@...il.com, eyal.birger@...il.com, jtoppins@...hat.com, shuah@...nel.org, linux-kselftest@...r.kernel.org Subject: Re: [PATCH net-next v7 1/2] Add nolocalbypass option to vxlan. Stephen Hemminger <stephen@...workplumber.org> writes: > On Tue, 2 May 2023 00:25:29 +0800 > Vladimir Nikishkin <vladimir@...ishkin.pw> wrote: > >> If a packet needs to be encapsulated towards a local destination IP and >> a VXLAN device that matches the destination port and VNI exists, then >> the packet will be injected into the Rx path as if it was received by >> the target VXLAN device without undergoing encapsulation. If such a >> device does not exist, the packet will be dropped. >> >> There are scenarios where we do not want to drop such packets and >> instead want to let them be encapsulated and locally received by a user >> space program that post-processes these VXLAN packets. >> >> To that end, add a new VXLAN device attribute that controls whether such >> packets are dropped or not. When set ("localbypass") these packets are >> dropped and when unset ("nolocalbypass") the packets are encapsulated >> and locally delivered to the listening user space application. Default >> to "localbypass" to maintain existing behavior. >> >> Signed-off-by: Vladimir Nikishkin <vladimir@...ishkin.pw> > > Is there some way to use BPF for this. Rather than a special case > for some userspace program? Well, in the first patch this was not a special case, but rather change to the default behaviour. (Which, I guess has been a little too audacious.) I am not sure about BPF, but the concrete use-case I have is solvable by dedicating a packet to a bogus IP, and doing an nftables double-NAT (source and destination) to 127.0.0.1, which is the way I am solving this problem now, and I suspect, what most sysadmins who need this feature would be doing this without this patch. In fact, among all the people I have talked to about this issue (on #networking@...era.chat, and elsewhere), nobody considered dropping packets to be an intuitive thing. The "intuitive logic" here is the following: 1) I am sending packets to an ip and a port, 2) I have a process listening to packets on this IP and port, 3) Why on Earth are packets not arriving? 4) Even further, why does local behaviour differ from remote behaviour? So the "special case" is already there by design. The new option is turning off the special case. I am aware of the fact that heavy-duty network processing people have a different perspective on this issue, and that in high-load environments every tiny bit of performance is of crucial importance, hence "local bypass" is seen not as a dirty heuristic, but rather as an essential feature which vastly increases performance, but for "kitchen sink" sysadmins the current (not documented) behaviour is just baffling. So I would argue that having an option that, even though it might not be the most frequently used one, is clearly documented as enabling the most straightforward behaviour, would be worth it. And although having a userspace process listening to a vxlan "for processing" might not be the most frequently used thing (although I do need it), at least being able to see the packets being sent to local ports, with, say, tcpdump, in exactly the same way as the packets being sent to remote addresses, would help sysadmins debug their setups better even when only the most basic tools available. I hope that this is convincing enough. P.S. A apologise for not adding the vxlan: and testing/selftests/net: prefixes to the patches. I will add them to the next attempt, in addition to fixing the other issues that might be discovered. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) -- Fastmail.
Powered by blists - more mailing lists