netdev - Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

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: <20240726131106.GW3371438@nvidia.com>
Date: Fri, 26 Jul 2024 10:11:06 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Jiri Kosina <jikos@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>, ksummit@...ts.linux.dev,
	linux-cxl@...r.kernel.org, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

On Fri, Jul 26, 2024 at 03:49:49PM +0300, Laurent Pinchart wrote:

> What is not an option exactly in my description above ? We have multiple
> V4L2 drivers for ISPs. They receive ISP parameters from userspace
> through a data buffer. It's not allowed to be opaque, but it doesn't
> prevent vendor closed-source userspace implementations with additional
> *camera* features, as long as the *hardware* features are available to
> everybody.

How far do you take opaque?

In mlx5 we pass command buffers from user to kernel to HW and the
kernel does only a little checking.

There is a 12kloc file describing the layout of alot of commands:
include/linux/mlx5/mlx5_ifc.h

There is an open PDF describing in detail some subset of this:
https://network.nvidia.com/files/doc-2020/ethernet-adapters-programming-manual.pdf

There are in-kernel implementations driving most of those commands.

Other commands are only issued by userspace, and we have open source
DPDK, rdma-core and UCX implementations driving them.

ie, this is really quite good as far as a device providing open source
solutions goes.

However, no doubt there is more FW capability and commands than even
this vast amount documents - so lets guess that propritary code is
using this interface with unknown commands too.

>From a camera perspective would you be OK with that? Let's guess that
90% of use cases are covered with fully open code. Do we also need to
forcefully close the door to an imagined 10% of proprietary cases just
to be sure open always wins?

Does closing the door have to come at the cost of a technically clean
solution? Doing validation in the kernel to enforce an ideological
position would severely degrade mlx5, and would probably never really
be robust.

Jason