Message-ID: <20240711180100.00006b96@Huawei.com>
Date: Thu, 11 Jul 2024 18:01:00 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Dan Williams <dan.j.williams@...el.com>, James Bottomley
	<James.Bottomley@...senpartnership.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 Thu, 11 Jul 2024 12:05:59 -0300
Jason Gunthorpe <jgg@...dia.com> wrote:

> On Wed, Jul 10, 2024 at 02:22:38PM +0100, Jonathan Cameron wrote:
> > On Tue, 9 Jul 2024 15:15:13 -0700
> > Dan Williams <dan.j.williams@...el.com> wrote:
> >   
> > > 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.  
> > 
> > I was resisting rat holing. Oh well...
> > 
> > For a 'subset' of CXL.  There are a wide range of controls that are highly
> > destructive, potentially to other hosts (simplest one is a command that
> > will surprise remove someone else's memory).  
> 
> I don't know alot of CXL, but from talking with Dan and reading these
> posts it seems to me that CXL turn into a network, with switches and
> multi-node and then somehow hid some kind of 'raw packet' interface to
> communicate node-to-node. But never added any kind of node level
> authorization? ie trust the nodes not to hurt each other?

You can't actually communicate node to node in the sense of host
to host.  You can just unplug stuff on another other host
(I guess that's a low bandwith comms channel...)
Data access should not be possible in general (ignoring shared
memory which is unrelated to the control path).
Control plane for the nasty stuff should all be in control
of one entity in the system - termed a fabric manager.

> 
> Sounds sketchy to me :)

Yes. The model is with the intent that this is only exposed by
hardware to a BMC / Fabric Manager - so security is by wiring.
The reason it's exposed on a PCI upstream port on a switch is that
there are designs where the Fabric manager is 'just another host'.
It's probably not running general software but that Fabric Manager
is running Linux too.  This isn't hugely different to not wiring
your MCTP management interface directly to the host such that the
OS can mess with it.

> 
> > So if fwctl is adopted, I do want the means to use it for the highly
> > destructive stuff as well!  Maybe that's a future discussion.  
> 
> With that kind of security model you probably have to trust the
> userspace, even in a lockdown kernel.

Agreed - but if we put infrastructure in place I want it to support
this as well.

> 
> ie can userspace replace the CXL HW that has the command interface
> with VFIO and then do anything with nothing more than CAP_SYS_ADMIN
> and root?

Yes if the wiring put that special PCI function on your PCI hierarchy.

> 
> If so it is not unreasonable that a fwctl interface has a similar
> level of protection.
> 
> > > 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.  
> > 
> > Worth asking if this will incorporate unknown but not vendor defined
> > commands.  There is a long tail of stuff in the spec we haven't caught up
> > with yet.  Or you thinking keep this for the strictly vendor defined stuff?  
> 
> I would allow as much as possible in fwctl that meets the defined
> functional limitations and security model.
> 
> There is security merit in saying userspace will run, parse and
> convert to output complex commands if it can safely do so. From an end
> user perspective running a common tool to view the output is generally
> always preferred anyhow, and the typical user doesn't really care if
> the tool trundles through sysfs or does something else.

Fair enough.  A bit of potential duplication won't be too painful
(fwctl vs stuff that we know is safe enough for a 'normal' interface).

Thanks,

Jonathan
> 
> Jason

Powered by blists - more mailing lists