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: <668db67196ca3_1bc8329416@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 9 Jul 2024 15:15:13 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>, Dan Williams
	<dan.j.williams@...el.com>, <ksummit@...ts.linux.dev>
CC: <linux-cxl@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
	<netdev@...r.kernel.org>, <jgg@...dia.com>
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

James Bottomley wrote:
> > 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.
> 
> I'm with Greg on this ... can you point to some of the contrary
> positions?

This thread has that discussion:

http://lore.kernel.org/0-v1-9912f1a11620+2a-fwctl_jgg@nvidia.com

I do not want to speak for others on the saliency of their points, all I
can say is that the contrary positions have so far not moved me to drop
consideration of fwctl for CXL.

Where CXL has a Command Effects Log that is a reasonable protocol for
making decisions about opaque command codes, and that CXL already has a
few years of experience with the commands that *do* need a Linux-command
wrapper.

Some open questions from that thread are: what does it mean for the fate
of a proposal if one subsystem Acks the ABI and another Naks it for a
device that crosses subsystem functionality? Would a cynical hardware
response just lead to plumbing an NVME admin queue, or CXL mailbox to
get device-specific commands past another subsystem's objection?

My reconsideration of the "debug-build only" policy for CXL
device-specific commands was influenced by a conversation with a distro
developer where they asserted, paraphrasing: "at what point is a device
vendor incentivized to ship an out-of-tree module just to restore their
passthrough functionality?. At that point upstream has lost out on
collaboration and distro kernel ABI has gained another out-of-tree
consumer."

So the tension is healthy, but it has diminishing returns past a certain
point.