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: <163766631025.3372.17600281769888147460@kwain>
Date:   Tue, 23 Nov 2021 12:18:30 +0100
From:   Antoine Tenart <atenart@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, alexander.duyck@...il.com,
        netdev@...r.kernel.org, Michal Kubecek <mkubecek@...e.cz>
Subject: Re: [PATCH net v2] net: avoid registering new queue objects after device unregistration

Quoting Jakub Kicinski (2021-11-22 20:37:42)
> On Mon, 22 Nov 2021 17:56:06 +0100 Antoine Tenart wrote:
> > Quoting Jakub Kicinski (2021-11-22 17:31:44)
> > > On Mon, 22 Nov 2021 17:20:07 +0100 Antoine Tenart wrote:  
> > > >    veth_set_channels+0x1c3/0x550
> > > >    ethnl_set_channels+0x524/0x610  
> > > 
> > > The patch looks fine, but ethtool calls should not happen after
> > > unregister IMHO. Too many drivers would be surprised. 
> > > 
> > > Maybe we should catch unregistered devices in ethnl_ops_begin()?  
> > 
> > That might be good to have indeed, I'll have a look. I'm not sure about
> > other paths that could do the same: if there are, we might want to keep
> > the check in this patch as well. Or WARN to catch future misuses?
> 
> My knee jerk reaction was to add a WARN() just because I can't think
> why changing queue count after unregister would be needed. But it's not
> really illegal and we do support it before register, so why not after
> unregister..

It's a little tricky. The queue count can be changed before
registration (updating dev->real_num_rx/tx_queues only) but the queue
objects can't[1]. The symmetry would be to only allowing to update
dev->real_num_tx_queues after unregister (which seems useless).

This is what's actually done for Rx queues[2]. For Tx the issue we have
is a quirk that was added to allow qdiscs to remove their extra Tx
queues after unregister[3] as in unregister_netdevice_many the net
devices are unlisted and moved to NETREG_UNREGISTERING before the call
to dev_shutdown().

[1] https://elixir.bootlin.com/linux/v5.16-rc2/source/net/core/dev.c#L2918
[2] https://elixir.bootlin.com/linux/v5.16-rc2/source/net/core/dev.c#L2967
[3] 5c56580b74e5 ("net: Adjust TX queue kobjects if number of queues
    changes during unregister")

> We can venture a warning with a comment saying that this is just for
> catching bad uses and see if any driver hits it on a normal path?

With that a better fix seems to be what you suggested, in
ethnl_ops_begin. A WARN in netdev_queue_update_kobjects[4] detecting
misuses might be good as well as the logic is not that straightforward
here.

[4] Or in netif_set_real_num_tx_queues as it is already detecting when
    queues are being disabled. !disabling && NETREG_UNREGISTERING should
    be illegal or at least not update the kobjects.
    https://elixir.bootlin.com/linux/v5.16-rc2/source/net/core/dev.c#L2913

Thanks!
Antoine

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ