netdev - Re: [PATCH net-next 01/15] sfc: support setting MTU even if not privileged to configure MAC fully

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] [day] [month] [year] [list]

Message-ID: <dcf4cd6d-852e-470c-97d7-9ecac2b01909@solarflare.com>
Date:   Thu, 2 Jul 2020 13:52:08 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <linux-net-drivers@...arflare.com>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>,
        Matthew Slattery <mslattery@...arflare.com>
Subject: Re: [PATCH net-next 01/15] sfc: support setting MTU even if not
 privileged to configure MAC fully

On 02/07/2020 00:16, Jakub Kicinski wrote:
> I see. I'm actually asking because of efx_ef10_set_udp_tnl_ports().
> I'd like to rewrite the UDP tunnel code so that 
> NETIF_F_RX_UDP_TUNNEL_PORT only appears on the interface if it 
> _really_ can do the offload. ef10 is the only driver I've seen where 
> I can't be sure what FW will say.. (other than liquidio, but that's 
> more of a kernel<->FW proxy than a driver, sigh).
I suppose it's time for me to describe the gory details ofhow EF10
 tunnel offloads work, then.  When changing the list of UDP tunnel
 ports, the MC patches the header-recogniser firmware and reboots
 the datapath CPUs (packet parsing on EF10 is done on a pair of
 DPCPUs with specialised instruction set extensions, and it wasn't
 originally designed with tunnel offloads in mind).  Unfortunately,
 to synchronise everything afterwards, the MC then has to reboot
 itself too.
Needless to say, this is fairly disruptive, especially as it's
 global across _both_ ports of a two-port NIC (which is what that
 EIO check in efx_ef10_set_udp_tnl_ports() is about: when you bring
 up a tunnel device, both netdevs get the ndo callback, the first
 one offloads the port, causing a reboot, which interrupts the
 second port's MCDI.  Once the MC comes back up, the second netdev
 tries again to offload the UDP port, and this time the MC only has
 to increase a refcount, since the first netdev already added that
 port, so it can return success without another reboot).

> Is there anything I can condition on there?
I _believe_ this is determined by another drv_attach flag,
 MC_CMD_DRV_ATTACH_EXT_OUT_FLAG_TRUSTED, but again I'm not 100%
 sure; it might be the PRIMARY flag instead.  I've CCed Matthew
 Slattery from our firmware team who should be able to answer.
It also depends on the VXLAN_NVGRE firmware capability, which
 efx_ef10_set_udp_tnl_ports() already checks.  Note that firmware
 capabilities can also change on an MC reboot (see the code that
 handles nic_data->must_check_datapath_caps).

-ed