netdev - Re: [PATCH net-next] ethtool: add tunable api to disable various firmware offloads

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: <20240816105126.080acb51@kernel.org>
Date: Fri, 16 Aug 2024 10:51:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Maciej Żenczykowski <maze@...gle.com>
Cc: Florian Fainelli <f.fainelli@...il.com>, Linux Network Development
 Mailing List <netdev@...r.kernel.org>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, "Kory Maincent (Dent Project)"
 <kory.maincent@...tlin.com>, Ahmed Zaki <ahmed.zaki@...el.com>, Edward Cree
 <ecree.xilinx@...il.com>, Yuyang Huang <yuyanghuang@...gle.com>, Lorenzo
 Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next] ethtool: add tunable api to disable various
 firmware offloads

On Thu, 15 Aug 2024 17:49:42 -0700 Maciej Żenczykowski wrote:
> I am of course in a very hard position here, as I don't own any
> drivers/firmware - AFAIK even Pixel's wifi/cell drivers aren't Google
> owned/maintained, but rather Broadcom/Synaptics/Qualcomm/Mediatek/etc
> as appropriate...
> 
> I do know there is a need for an api of this sort (not necessarily
> exactly this patch though), and if we merge something (sane :-) ) into
> Linux, we can then backport that (either to LTS or just to ACK), and
> then we (as in Google) can require implementations (for new
> hardware/drivers) in future versions of Android...

That's why I'm suggesting the LLDP in the Intel Ethernet driver.
Others may disagree but for me it's close enough to merge a "enable
L2 protocol agent" sort of an API. We don't need to have upstream users
for each proto. Bigger cause of sadness is that the API IIUC is a part
of a deprecation path, IOW once APF comes, it will become dead weight.
Luckily it's not a lot of code.

> Presumably that would result in implementations in many drivers,
> though not necessarily any in-tree ones (I have no idea what the
> current state of in-vs-out-of-tree drivers is wrt. Android wifi/cell
> hardware)
> 
> This is very much a chicken-and-egg problem though.  As long as there
> is no 'public' API, the default approach is for per-vendor or even
> per-chip / per-driver custom apis, hidden behind Android HALs.  For
> example we have such an Android HAL api for disabling ND offload on at
> least one of our devices.  Of course the HAL itself is backed by
> calling into the driver - just over some driver specific netlink...

I wonder if there's anything we can share between APF style offloads
and Jamal's P4 work, if it materializes.