linux-kernel - Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

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]

Date: Mon, 29 Apr 2024 19:36:41 -0600
From: David Ahern <dsahern@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Christoph Hellwig <hch@...radead.org>, Saeed Mahameed <saeed@...nel.org>,
 Arnd Bergmann <arnd@...db.de>, Leon Romanovsky <leonro@...dia.com>,
 Jiri Pirko <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>,
 Itay Avraham <itayavr@...dia.com>, Jakub Kicinski <kuba@...nel.org>,
 Saeed Mahameed <saeedm@...dia.com>,
 Aron Silverton <aron.silverton@...cle.com>, linux-kernel@...r.kernel.org,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

On 3/4/24 9:02 AM, Jason Gunthorpe wrote:
> On Wed, Feb 14, 2024 at 01:57:35PM -0400, Jason Gunthorpe wrote:
> 
>> I also like this, I don't want the outcome of this discussion to be
>> that only mlx5ctl gets merged. I want all the HW that has this problem
>> to have support in the mainline kernel.
> 
> To this end here is my proposal to move forward with a new
> mini-subsystem to provide rules for this common approach. Get the
> existing tools out of hacky unstructured direct hardware access via
> /sys/XX and into a formalized lockdown compatible system. I've talked
> to enough people now to think we have a critical mass.
> 
> ===============
> fwctl subsystem
> ===============

The aux bus infrastructure was created specifically for multifunction
devices -- it allows a core PCI device driver with smaller, subsystem
focused drivers for vendor specific implementations of various S/W stack
APIs (IB, netdev, etc). One aspect not addressed in that design is where
to park the various drivers and extensions that are not solely tied to
any one subsystem.

Given, that how about moving the existing auxbus code into a new
directory, drivers/auxbus. From there, create a subdirectory for this
new fwctl subsystem which is most likely to be realized as a new auxbus
device and then subdirectories for vendor specific drivers for the aux
bus device. Then new drivers being developed in this auxbus world can
put the core PCI device handling code under drivers/auxbus/core.

In short:
- drivers/auxbus/auxiliary.c

- drivers/auxbus/core/<vendor>/  - per h/w device driver for managing
the PCI device which is shared across multiple auxbus devices

- drivers/auxbus/fwctl/fwctl.c   - this FW interface

- drivers/auxbus/fwctl/<vendor>/ - vendor specific driver for a fwctl
auxbus device