netdev - Re: [PATCH net-next 0/5] net: flower: validate encapsulation control flags

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 13 Jun 2024 17:38:17 +0000
From: Asbjørn Sloth Tønnesen <ast@...erby.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Edward Cree <ecree.xilinx@...il.com>,
 Martin Habets <habetsm.xilinx@...il.com>, linux-net-drivers@....com,
 Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky <leon@...nel.org>,
 Tariq Toukan <tariqt@...dia.com>, linux-rdma@...r.kernel.org,
 Jesse Brandeburg <jesse.brandeburg@...el.com>,
 Tony Nguyen <anthony.l.nguyen@...el.com>, intel-wired-lan@...ts.osuosl.org,
 Louis Peens <louis.peens@...igine.com>, oss-drivers@...igine.com,
 linux-kernel@...r.kernel.org, Davide Caratti <dcaratti@...hat.com>,
 i.maximets@....org
Subject: Re: [PATCH net-next 0/5] net: flower: validate encapsulation control
 flags

Hi Jakub,

On 6/13/24 1:04 AM, Jakub Kicinski wrote:
> On Sun,  9 Jun 2024 17:33:50 +0000 Asbjørn Sloth Tønnesen wrote:
>> Now that all drivers properly rejects unsupported flower control flags
>> used with FLOW_DISSECTOR_KEY_CONTROL, then time has come to add similar
>> checks to the drivers supporting FLOW_DISSECTOR_KEY_ENC_CONTROL.
> 
> Thanks for doing this work!

Thank you, for maintaining the tree!

> Do you have any more of such series left?

Not at the moment, I only stumbled upon this, because I read the code
with an eye on adding a new IS_JUMBO_FRAME flag (patches for which are
almost ready).

Once this[1] currently RFC patch goes in, I might try to move all
control flags in under FLOW_DIS_F_*, to get rid of the then
FLOW_DIS_(IS_FRAGMENT|FIRST_FRAG|ENCAPSULATION|F_*).

[1] [RFC PATCH net-next 1/9] net/sched: flower: define new tunnel flags
https://lore.kernel.org/netdev/20240611235355.177667-2-ast@fiberby.net/

> Could we perhaps consider
> recording the driver support somewhere in struct net_device and do
> the rejecting in the core?

Sure, it could work for the control flags, and used_keys validation,
but I am not sure if it is worth it, as most of the validation is
very specific to the limitations of the different hardware. An easy
first step in that direction would be to move the used_keys checks
behind a helper, and possibly storing used_keys in struct net_device.

> That's much easier to extend when adding
> new flags than updating all the drivers.

That's how it is now, with the new helpers, as all flags are
unsupported, unless the driver specifically supports it.

Any new flag only needs to be added to the core, and drivers only needs
to be updated when they implement offloading support for a flag.

> This series I think may not be a great first candidate as IIUC all
> drivers would reject so the flag would be half-dead...

Correct. I don't know if there is any hardware support planned for the
tunnel-related encapsulation control flags.

-- 
Best regards
Asbjørn Sloth Tønnesen
Network Engineer
Fiberby - AS42541