netdev - Re: [PATCH v4 03/14] net: ionic: Export the APIs from net driver to support device commands

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]

Message-ID: <5d495e57-71f5-e465-cba0-d727c6b36167@amd.com>
Date: Wed, 6 Aug 2025 13:24:04 +0530
From: Abhijit Gangurde <abhijit.gangurde@....com>
To: Jakub Kicinski <kuba@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
 Simon Horman <horms@...nel.org>
Cc: shannon.nelson@....com, brett.creeley@....com, davem@...emloft.net,
 edumazet@...gle.com, pabeni@...hat.com, corbet@....net, leon@...nel.org,
 andrew+netdev@...n.ch, allen.hubbe@....com, nikhil.agarwal@....com,
 linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 03/14] net: ionic: Export the APIs from net driver to
 support device commands

On 8/2/25 01:51, Jakub Kicinski wrote:
> On Fri, 1 Aug 2025 14:00:14 -0300 Jason Gunthorpe wrote:
>>> Perhaps I misunderstand things, or otherwise am on the wrong track here.
>>> But this seems to open the possibility of users of ionic_adminq_post_wait(),
>>> outside the Ethernet driver, executing a wide range or admin commands.
>>> It seems to me that it would be nice to narrow that surface.
>> The kernel is monolithic, it is not normal to spend performance
>> aggressively policing APIs.
>>
>> mlx5 and other drivers already have interfaces almost exactly like this.
> Which is not to say that it's a good idea.

Thank you for the feedback, and apologies for the delay. This discussion 
prompted a thorough internal review.
Although a precedent for similar interfaces exists in other RDMA 
drivers, the point is well-taken and we understand the concern about a 
wide API. To address this, two potential approaches are being considered,
1. The function can be documented as a privileged, clarifying that it 
performs no input sanitization and making the caller responsible for 
device access.
2. Alternatively, a new, narrower function could be introduced 
specifically for RDMA use that validates commands against an explicit 
allow list.

We are open to either approach and would appreciate a guidance on the 
preferred direction.

Abhijit