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

[Edward Cree]

 disclaimer.sh

On 04/04/2024 19:33, Jason Gunthorpe wrote:
> Uh no, mlx5 already has an excellent in-tree driver, thank you very
> much.

I was referring to *mlx5ctl*, which is not currently in-tree, which
 is why this thread trying to add it exists in the first place.

> So, it is really some kind of extremism to say that allowing users to
> configure the device in their own system in a booted Linux OS instead

Um, nothing upstream does is stopping them installing an OOT mlx5ctl
 driver, *if* that's what they want to do.  Clearly some of them don't
 like that solution, otherwise we wouldn't be here.

> 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).
It is just that the latter case, if done through an intree driver,
 would appear to be (and might be marketed as) an open-source developed
 product, which users would naturally expect to have those benefits,
 when in fact it doesn't.

>> So because your engineers can't design clean, orthogonal APIs for
>>  toffee, you should be allowed to bypass review?  Sorry, but no.
> 
> Overreach. The job of the kernel maintainer is to review the driver
> software, not the device design.

Really? [1]
The kernel always has the choice to not support a given device, or a
 given feature of a device; and kernel maintainers are precisely the
 people with both the right and the duty to make that determination.

> If you had read the thread to understand the issue, you'd know this is
> because the distros have turned on module signing, secure boot and
> kernel lock down.

Funnily enough, I am aware of that.
And if your customers didn't want those things, they'd be quite capable
 of forking the distro to undo it.  Several hyperscalers already have
 their own in-house distros anyway.
They could add their own signing key to the kernel, and sign your ctl
 driver with it.
They could disable lockdown, or patch the kernel to allow your
 (hopefully signed and IMA-ed) userspace tool to do its PCI-over-sysfs
 crap even when lockdown blocks it for everything else.
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.

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

-ed

[1]: https://wiki.linuxfoundation.org/networking/toe