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

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

Date: Fri, 5 Apr 2024 08:21:00 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: David Ahern <dsahern@...nel.org>, Jakub Kicinski <kuba@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	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>,
	Saeed Mahameed <saeedm@...dia.com>,
	Aron Silverton <aron.silverton@...cle.com>,
	linux-kernel@...r.kernel.org,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

On Thu, Apr 04, 2024 at 08:31:24PM +0100, Edward Cree wrote:
> > of in the factory looses the "implied engineering benefits of open
> > source".
> 
> You're looking at the wrong point on the causal graph.
> Whether you apply the hacks in the factory or at runtime, their hacky
>  design is what prevents them from having the benefits of open source
>  (because those benefits consist of a development process that weeds
>  out hacks and bad design).

Oh please. They are not hacks, you are inventing this idea entirely
out of thin air based on your own lack of detailed knowledge or
personal aesthetic preferences.

> > Overreach. The job of the kernel maintainer is to review the driver
> > software, not the device design.
> 
> Really? [1]

Yep. TOEs are supported in the RDMA stack.

The only thing the kernel community decided was that a TOE cannot be
accessed using the socket API, the HW is still supported.

> But strangely, there are people out there who trust the upstream process
>  to ensure quality/security/etc. more than they trust vendors and their
>  "oh don't worry, the device will enforce security scopes on these raw
>  commands from userspace" magic firmware blobs.

Upstream Linux community has already decided trusting firwmare is
acceptable. I gave many examples in the fwctl document if you'd care
to understand it.

And of course we get the usual garbage solution "oh just fork linux"
which *completely misses the point* of what Linux really is or what
the community is fundamentally seeking to achieve.

> What you are asking for here is a special exemption to all those
>  requirements and security measures because "just trust me bro".

Actually no, fwctl is following accepted kernel design principles with
many prior examples.

Jason