Message-ID: <668c67a324609_ed99294c0@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 8 Jul 2024 15:26:43 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: <ksummit@...ts.linux.dev>
CC: <linux-cxl@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
	<netdev@...r.kernel.org>, <jgg@...dia.com>
Subject: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

Early in my Linux career there was palpable concern around Linux being
locked out of future computing platforms by hardware vendors who did not
provide open drivers, or even documentation for their hardware. For the
hardware vendors that did participate upstream, maintainers used code
acceptance to influence them towards common Linux commands and
cross-vendor cooperation.

The internalized lesson from those days was: "Be wary of vendors pushing
'do anything you want and get away with it' passthrough tunnels. Demand
open documentation of all interfaces."

Present day realities and discussions merit revisiting that lesson:

1/ The truth of the matter is that until the Kernel Lockdown facility
   arrived, device vendors *had* an unfettered passthrough tunnel via
   userspace driver mechanisms like /dev/mem and pci-sysfs. The presence of
   those facilities did not appear to injure the ascension of Linux.

2/ Device passthrough, kernel passing opaque payloads, is already taken
   for granted in many subsystems. USB and HID have "raw" interfaces, EFI
   variables provide platform-specific configuration, and the oft-cited
   examples of SCSI and NVME that provide facilities to marshal any command
   payload whether mainline maintainers think the functionality is a good
   idea or not. In the case of NVME, the specification continues to evolve
   despite this Linux bypass.

3/ The practice of requiring Linux commands to wrap all device commands
   does not appear to have accelerated upstream participation in the CXL
   subsystem. I.e. CXL, in contrast to NVME, relegates passthrough to a
   build-time debug option. Some vendors are even shipping vendor
   specific firmware update facilities even though mainline has support for
   the CXL standard firmware update mechanism.

   With the impending arrival of CXL switch devices wanting to share
   mailbox handling code with the CXL core, the prohibition of
   device-specific commands is going to generate significant upstream work
   to wrap all that in Linux commands with little perceivable long term
   benefit to the subsystem.

CXL and RDMA are also foreshadowing conflicts across subsystems. It is
not difficult to imagine a future CXL or RDMA device that supports mem,
block, net, and drm/accel functionality. Which subsystem's
device-command policy applies to such a thing?

Enter the fwctl proposal [1]. From the CXL subsystem perspective it
looks like a long-term solution to the problem of managing expectations
between hardware vendors and mainline subsystems. It disclaims support
for the fast-path (data-plane) and is targeted at the long tail of
slow-path (config/debug plane) device-specific operations that are often
uninteresting to mainline. It sets expectations that the device must
advertise the effect of all commands so that the kernel can deploy
reasonable Kernel Lockdown policy, or otherwise require CAP_SYS_RAWIO
for commands that may affect user-data. It sets common expectations for
device designers, distribution maintainers, and kernel developers. It is
complimentary to the Linux-command path for operations that need deeper
kernel coordination.

The upstream discussion has yielded the full spectrum of positions on
device specific functionality, and it is a topic that needs cross-kernel
consensus as hardware increasingly spans cross-subsystem concerns.
Please consider it for a Maintainers Summit discussion.

[1]: http://lore.kernel.org/0-v2-940e479ceba9+3821-fwctl_jgg@nvidia.com

Powered by blists - more mailing lists