linux-kernel - Re: RFC: Restricting userspace interfaces for CXL fabric management

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: <Zi3Pv1GrCY6bSk4e@acer.trudheim.com>
Date: Sun, 28 Apr 2024 06:25:35 +0200
From: Sirius <sirius@...dheim.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
	Harold Johnson <harold.johnson@...adcom.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	linux-cxl@...r.kernel.org,
	Sreenivas Bagalkote <sreenivas.bagalkote@...adcom.com>,
	Brett Henning <brett.henning@...adcom.com>,
	Sumanesh Samanta <sumanesh.samanta@...adcom.com>,
	linux-kernel@...r.kernel.org, Davidlohr Bueso <dave@...olabs.net>,
	Dave Jiang <dave.jiang@...el.com>,
	Alison Schofield <alison.schofield@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Ira Weiny <ira.weiny@...el.com>, linuxarm@...wei.com,
	linux-api@...r.kernel.org,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	"Natu, Mahesh" <mahesh.natu@...el.com>
Subject: Re: RFC: Restricting userspace interfaces for CXL fabric management

In days of yore (Sat, 27 Apr 2024), Dan Williams thus quoth: 
> Greg KH wrote:
> [..]
> > So while innovating at the hardware level is fine, follow the ways that
> > everyone has done this for other specification types (USB, PCI, etc.)
> > and just allow vendor drivers to provide the information.  Don't do this
> > in crazy userspace drivers which will circumvent the whole reason we
> > have standard kernel/user apis in the first place for these types of
> > things.
> 
> Right, standard kernel/user apis is the requirement.
> 
> The suggestion of opaque vendor passthrough tunnels, and every vendor
> ships their custom tool to do what should be common flows, is where this
> discussion went off the rails.

One aspect of this is Fabric Management (thinking CXL3 here). It is not
desirable that every vendor of CXL hardware require their own
(proprietary) fabric management software. From a user perspective, that is
absolutely horrible. Users can, and will, mix and match CXL hardware
according to their needs (or wallet), and them having to run multiple
fabric management solutions (which in worst case are conflicting with each
other) to manage things is .. suboptimal.

By all means - innovate - but do it in such a way that interoperability
and manageability is the priority. Special sauce vendor lock-in is a
surefire way to kill CXL where it stands - don't do it.

-- 
Kind regards,

/S