linux-kernel - Re: [ovs-dev] [PATCH net] openvswitch: Set the skbuff pkt

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 25 Mar 2024 13:37:41 +0100
From: Ilya Maximets <i.maximets@....org>
To: Aaron Conole <aconole@...hat.com>, Eelco Chaudron <echaudro@...hat.com>
Cc: dev@...nvswitch.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 "David S. Miller" <davem@...emloft.net>, i.maximets@....org
Subject: Re: [ovs-dev] [PATCH net] openvswitch: Set the skbuff pkt_type for
 proper pmtud support.

On 3/25/24 13:22, Aaron Conole wrote:
> Eelco Chaudron <echaudro@...hat.com> writes:
> 
>> On 22 Mar 2024, at 20:06, Aaron Conole wrote:
>>
>>> Open vSwitch is originally intended to switch at layer 2, only dealing with
>>> Ethernet frames.  With the introduction of l3 tunnels support, it crossed
>>> into the realm of needing to care a bit about some routing details when
>>> making forwarding decisions.  If an oversized packet would need to be
>>> fragmented during this forwarding decision, there is a chance for pmtu
>>> to get involved and generate a routing exception.  This is gated by the
>>> skbuff->pkt_type field.
>>>
>>> When a flow is already loaded into the openvswitch module this field is
>>> set up and transitioned properly as a packet moves from one port to
>>> another.  In the case that a packet execute is invoked after a flow is
>>> newly installed this field is not properly initialized.  This causes the
>>> pmtud mechanism to omit sending the required exception messages across
>>> the tunnel boundary and a second attempt needs to be made to make sure
>>> that the routing exception is properly setup.  To fix this, we set the
>>> outgoing packet's pkt_type to PACKET_OUTGOING, since it can only get
>>> to the openvswitch module via a port device or packet command.
>>
>> Is this not a problem when the packet comes from the bridge port in the kernel?
> 
> It very well may be an issue there as well, but the recommendation is to
> operate with the bridge port down as far as I know, so I don't know if
> this issue has been observed happening from the bridge port.

FWIW, bridge ports are typically used as an entry point for tunneled
traffic so it can egress from a physical port attached to OVS.  It means
they are pretty much always UP in most common setups like OpenStack or
ovn-kubernetes and handle a decent amount of traffic.  They are also used
to direct some other types of traffic to the host kernel.

Unless I misunderstood which ports we're talking about here.

Best regards, Ilya Maximets.