netdev - Re: [PATCH net-next] ethtool: Fail number of channels change when it conflicts with rxnfc

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]

Date:   Mon, 31 Oct 2022 18:23:48 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Gal Pressman <gal@...dia.com>
Cc:     "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Tariq Toukan <tariqt@...dia.com>
Subject: Re: [PATCH net-next] ethtool: Fail number of channels change when
 it conflicts with rxnfc

On Mon, 31 Oct 2022 12:00:16 +0200 Gal Pressman wrote:
> Similar to what we do with the hash indirection table [1], when network
> flow classification rules are forwarding traffic to channels greater
> than the requested number of channels, fail the operation.
> Without this, traffic could be directed to channels which no longer
> exist (dropped) after changing number of channels.
> 
> [1] commit d4ab4286276f ("ethtool: correctly ensure {GS}CHANNELS doesn't conflict with GS{RXFH}")

Have you made sure there are no magic encodings of queue numbers this
would break? I seem to recall some vendors used magic queue values to
redirect to VFs before TC and switchdev. If that's the case we'd need
to locate the drivers that do that and flag them so we can enforce this
only going forward?