netdev - Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

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: <7f728d06-3a8b-945b-de0f-d0691d3c1eab@iogearbox.net>
Date: Fri, 5 Apr 2024 15:06:19 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Jason Gunthorpe <jgg@...dia.com>, Paolo Abeni <pabeni@...hat.com>
Cc: Alexander Duyck <alexander.duyck@...il.com>,
 Jakub Kicinski <kuba@...nel.org>, John Fastabend <john.fastabend@...il.com>,
 Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, bhelgaas@...gle.com,
 linux-pci@...r.kernel.org, Alexander Duyck <alexanderduyck@...com>,
 davem@...emloft.net, Christoph Hellwig <hch@....de>
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On 4/5/24 2:26 PM, Jason Gunthorpe wrote:
> On Fri, Apr 05, 2024 at 09:11:19AM +0200, Paolo Abeni wrote:
>> On Thu, 2024-04-04 at 17:11 -0700, Alexander Duyck wrote:
>>> Again, I would say we look at the blast radius. That is how we should
>>> be measuring any change. At this point the driver is self contained
>>> into /drivers/net/ethernet/meta/fbnic/. It isn't exporting anything
>>> outside that directory, and it can be switched off via Kconfig.
>>
>> I personally think this is the most relevant point. This is just a new
>> NIC driver, completely self-encapsulated. I quickly glanced over the
>> code and it looks like it's not doing anything obviously bad. It really
>> looks like an usual, legit, NIC driver.
> 
> This is completely true, and as I've said many times the kernel as a
> project is substantially about supporting the HW that people actually
> build. There is no reason not to merge yet another basic netdev
> driver.
> 
> However, there is also a pretty strong red line in Linux where people
> belive, with strong conviction, that kernel code should not be merged
> only to support a propriety userspace. This submission is clearly
> bluring that line. This driver will only run in Meta's proprietary
> kernel fork on servers running Meta's propriety userspace.
> 
> At this point perhaps it is OK, a basic NIC driver is not really an
> issue, but Jiri is also very correct to point out that this is heading
> in a very concerning direction.
> 
> Alex already indicated new features are coming, changes to the core
> code will be proposed. How should those be evaluated? Hypothetically
> should fbnic be allowed to be the first implementation of something
> invasive like Mina's DMABUF work?
My $0.02 from only reading this thread on the side.. when it comes to
extending and integrating with core networking code (e.g. larger features
like offloads, xdp/af_xdp, etc) the networking community always requested
at least two driver implementations to show-case that the code extensions
touching core code are not unique to just a single driver/NIC/vendor. I'd
expect this holds true also here..