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: <20250806175818.GV402218@unreal>
Date: Wed, 6 Aug 2025 20:58:18 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Abhijit Gangurde <abhijit.gangurde@....com>
Cc: Jakub Kicinski <kuba@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>,
	Simon Horman <horms@...nel.org>, shannon.nelson@....com,
	brett.creeley@....com, davem@...emloft.net, edumazet@...gle.com,
	pabeni@...hat.com, corbet@....net, 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 Wed, Aug 06, 2025 at 01:24:04PM +0530, Abhijit Gangurde wrote:
> 
> 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.

I suggest you to take standard kernel coding pattern and create
in-kernel API which suits your "in-kernel customers". There is no
need in any "allow list" for in-kernel APIs. Let's don't bring
complexity and defense programming style where it is not needed
and here it is not needed.

Thanks

> 
> Abhijit
> 
>