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: <c04242ee-f125-6d95-e263-65470222d3cf@ovn.org>
Date:   Wed, 23 Nov 2022 22:22:23 +0100
From:   Ilya Maximets <i.maximets@....org>
To:     Aaron Conole <aconole@...hat.com>, netdev@...r.kernel.org
Cc:     i.maximets@....org, Pravin B Shelar <pshelar@....org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Thomas Graf <tgraf@...g.ch>, dev@...nvswitch.org,
        Eelco Chaudron <echaudro@...hat.com>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [RFC net-next 1/6] openvswitch: exclude kernel flow key from
 upcalls

On 11/22/22 15:03, Aaron Conole wrote:
> When processing upcall commands, two groups of data are available to
> userspace for processing: the actual packet data and the kernel
> sw flow key data.  The inclusion of the flow key allows the userspace
> avoid running through the dissection again.
> 
> However, the userspace can choose to ignore the flow key data, as is
> the case in some ovs-vswitchd upcall processing.  For these messages,
> having the flow key data merely adds additional data to the upcall
> pipeline without any actual gain.  Userspace simply throws the data
> away anyway.

Hi, Aaron.  While it's true that OVS in userpsace is re-parsing the
packet from scratch and using the newly parsed key for the OpenFlow
translation, the kernel-porvided key is still used in a few important
places.  Mainly for the compatibility checking.  The use is described
here in more details:
  https://docs.kernel.org/networking/openvswitch.html#flow-key-compatibility

We need to compare the key generated in userspace with the key
generated by the kernel to know if it's safe to install the new flow
to the kernel, i.e. if the kernel and OVS userpsace are parsing the
packet in the same way.

On the other hand, OVS today doesn't check the data, it only checks
which fields are present.  So, if we can generate and pass the bitmap
of fields present in the key or something similar without sending the
full key, that might still save some CPU cycles and memory in the
socket buffer while preserving the ability to check for forward and
backward compatibility.  What do you think?


The rest of the patch set seems useful even without patch #1 though.

Nit: This patch #1 should probably be merged with the patch #6 and be
at the end of a patch set, so the selftest and the main code are updated
at the same time.

Best regards, Ilya Maximets.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ