netdev - Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable device offload setup

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: <61ea0316-2687-4928-a4d5-de20f3205c29@nbd.name>
Date: Fri, 1 Sep 2023 14:47:10 +0200
From: Felix Fietkau <nbd@....name>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC] netfilter: nf_tables: ignore -EOPNOTSUPP on flowtable
 device offload setup

On 01.09.23 14:29, Pablo Neira Ayuso wrote:
> On Fri, Sep 01, 2023 at 12:30:37PM +0200, Felix Fietkau wrote:
>> On 01.09.23 10:39, Pablo Neira Ayuso wrote:
>> > Hi Felix,
>> > 
>> > On Thu, Aug 31, 2023 at 10:14:20PM +0200, Felix Fietkau wrote:
>> > > On many embedded devices, it is common to configure flowtable offloading for
>> > > a mix of different devices, some of which have hardware offload support and
>> > > some of which don't.
>> > > The current code limits the ability of user space to properly set up such a
>> > > configuration by only allowing adding devices with hardware offload support to
>> > > a offload-enabled flowtable.
>> > > Given that offload-enabled flowtables also imply fallback to pure software
>> > > offloading, this limitation makes little sense.
>> > > Fix it by not bailing out when the offload setup returns -EOPNOTSUPP
>> > 
>> > Would you send a v2 to untoggle the offload flag when listing the
>> > ruleset if EOPNOTSUPP is reported? Thus, the user knows that no
>> > hardware offload is being used.
>> 
>> Wouldn't that mess up further updates to the flowtable? From what I can
>> tell, when updating a flow table, changing its offload flag is not
>> supported.
> 
> The flag would be untoggled if hardware offload is not supported. What
> problematic scenario are you having in mind that might break?

The scenario I'm thinking about is this:
Initially, the flowtable is created with a set of devices which don't 
support offload.
Afterwards, the flowtable gets updated with the intention of adding an 
extra device which *does* support hw offload to the existing flowtable.
If the flag was cleared after initially creating the table, I think the 
update would fail. Or did I misread the code?

> In any case, there is a need to provide a way to tell the user if the
> hardware offload is actually happening or not, if not what I suggest,
> then propose a different way. But user really needs to know if it runs
> software or hardware plane to debug issues.

In my opinion, a single flag indication for the flow table is mostly 
useless. Much more useful would be if you could query which of the 
devices that were added to the flowtable support hw offload and which 
ones don't. That requires some API changes though, and I don't think 
that should be done in this patch.

- Felix