linux-kernel - RE: [EXT] Re: [PATCH net-next v3 2/4] octeon

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: <PH0PR18MB4734652F50856F52507577ADC78FA@PH0PR18MB4734.namprd18.prod.outlook.com>
Date:   Mon, 11 Dec 2023 10:31:32 +0000
From:   Shinas Rasheed <srasheed@...vell.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Haseeb Gani <hgani@...vell.com>,
        Vimlesh Kumar <vimleshk@...vell.com>,
        "egallen@...hat.com" <egallen@...hat.com>,
        "mschmidt@...hat.com" <mschmidt@...hat.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "horms@...nel.org" <horms@...nel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wizhao@...hat.com" <wizhao@...hat.com>,
        "kheib@...hat.com" <kheib@...hat.com>,
        "konguyen@...hat.com" <konguyen@...hat.com>,
        Veerasenareddy Burru <vburru@...vell.com>,
        Sathesh B Edara <sedara@...vell.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: RE: [EXT] Re: [PATCH net-next v3 2/4] octeon_ep: PF-VF mailbox
 version support

Hi Leon,

> > @@ -28,10 +28,18 @@ static void octep_pfvf_validate_version(struct
> octep_device *oct,  u32 vf_id,
> >  {
> >  	u32 vf_version = (u32)cmd.s_version.version;
> >
> > -	if (vf_version <= OCTEP_PFVF_MBOX_VERSION_V1)
> > -		rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> > +	dev_dbg(&oct->pdev->dev, "VF id:%d VF version:%d PF
> version:%d\n",
> > +		vf_id, vf_version, OCTEP_PFVF_MBOX_VERSION_CURRENT);
> > +	if (vf_version < OCTEP_PFVF_MBOX_VERSION_CURRENT)
> > +		rsp->s_version.version = vf_version;
> >  	else
> > -		rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> > +		rsp->s_version.version =
> OCTEP_PFVF_MBOX_VERSION_CURRENT;
> > +
> > +	oct->vf_info[vf_id].mbox_version = rsp->s_version.version;
> > +	dev_dbg(&oct->pdev->dev, "VF id:%d negotiated VF version:%d\n",
> > +		vf_id, oct->vf_info[vf_id].mbox_version);
> > +
> > +	rsp->s_version.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
> >  }
> 
> <...>
> 
> > +#define OCTEP_PFVF_MBOX_VERSION_CURRENT
> 	OCTEP_PFVF_MBOX_VERSION_V1
> 
> This architecture design is unlikely to work in the real world unless
> you control both PF and VF environment. Mostly PF is running some old
> legacy distribution while VFs run more modern OS and this check will
> prevent to run new driver in VF.
> 
> Thanks

Thanks for the review. This version validation only concerns regarding the control net API layer (which is used to communicate with
the firmware). In the case you have described, this instead enables new VF drivers to atleast work atop legacy PF drivers (note legacy here still
refers to PF drivers which support this backward compatibility), although they might not be able to use the latest control net functionalities that they
have been enabled for.

In the absence of such a backward compatibility, VF drivers would issue control net requests which PF drivers wouldn't know, only leading to logs of
incompatibility errors and erroneous usage. 

Also again please note that this version compatibility only concerns the control net infrastructure and API (the control plane).