netdev - Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions

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]

Date:   Sat, 5 Oct 2019 22:01:08 +0000
From:   Jason Gunthorpe <jgg@...lanox.com>
To:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>
CC:     Leon Romanovsky <leon@...nel.org>,
        "dledford@...hat.com" <dledford@...hat.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Mustafa Ismail <mustafa.ismail@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Shiraz Saleem <shiraz.saleem@...el.com>
Subject: Re: [RFC 04/20] RDMA/irdma: Add driver framework definitions

On Fri, Oct 04, 2019 at 05:46:15PM -0700, Jeff Kirsher wrote:
> On Fri, 2019-10-04 at 23:45 +0000, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2019 at 01:12:22PM -0700, Jeff Kirsher wrote:
> > 
> > > > > +	if (ldev->version.major != I40E_CLIENT_VERSION_MAJOR ||
> > > > > +	    ldev->version.minor != I40E_CLIENT_VERSION_MINOR) {
> > > > > +		pr_err("version mismatch:\n");
> > > > > +		pr_err("expected major ver %d, caller specified
> > > > > major
> > > > > ver %d\n",
> > > > > +		       I40E_CLIENT_VERSION_MAJOR, ldev-
> > > > > >version.major);
> > > > > +		pr_err("expected minor ver %d, caller specified
> > > > > minor
> > > > > ver %d\n",
> > > > > +		       I40E_CLIENT_VERSION_MINOR, ldev-
> > > > > >version.minor);
> > > > > +		return -EINVAL;
> > > > > +	}
> > > > 
> > > > This is can't be in upstream code, we don't support out-of-tree
> > > > modules,
> > > > everything else will have proper versions.
> > > 
> > > Who is the "we" in this context?
> > 
> > Upstream sensibility - if we start doing stuff like this then we will
> > end up doing it everwhere.
> 
> I see you cut out the part of my response about Linux distributions
> disagreeing with this stance.

Sure, this is an upstream decision.. I think everyone knows distros
hate the stable-api-nonsense policy?

> > I don't see how this is any different from any of the other myriad of
> > problems out of tree modules face. 
> > 
> > Someone providing out of tree modules has to provide enough parts of
> > their driver so that it only consumes the stable ABI from the distro
> > kernel.
> > 
> > Pretty normal stuff really.
> 
> Your right, if the dependency was reversed and the out-of-tree (OOT) driver
> was dependent upon the RDMA driver, but in this case it is not.  The LAN
> driver does not "need" the RDMA driver to work.  So the RDMA driver should
> at least check that the LAN driver loaded has the required version to work.

So? IMHO you have to provide both drivers if you want to have an OOT
solution as the lan driver is providing and changing kABI outside the
distro promise of kABI stability.

It is no different than replacing, say, the entire core RDMA subsystem as
many people tend to do.

> This line of thinking, "marries" the in-kernel RDMA driver with the in-
> kernel LAN driver(s) so the end users and Linux distro's can not choose to
> upgrade or use any other driver than what comes with the kernel.  

Yes, but upgrade is possible, you have to provide both.

> agree that any out-of-tree (OOT) driver needs to make sure they have all
> kernel ABI's figured out for whatever kernel they are being installed on. 
> But what is the problem with the in-kernel RDMA driver to do it's own
> checks to ensure the driver it is dependent upon meets its minimum
> requirements?

It is against the upstream policy and we'd have a proliferation of
these checks if it was allowed, IMHO.
 
> Similar checks are done in the Intel LAN driver to ensure the firmware is
> of a certain level, which is no different than what is being done here.

External dependencies are expected to check compatability.

Jason