netdev - 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: <20231211112305.GD4870@unreal>
Date: Mon, 11 Dec 2023 13:23:05 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Shinas Rasheed <srasheed@...vell.com>
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

On Mon, Dec 11, 2023 at 10:31:32AM +0000, Shinas Rasheed wrote:
> 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.

The question what will be in X years from now, when you will have v100?
Will you fallback to v0 for backward compatibility? 

> 
> 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).

It doesn't matter, even in best scenario, you can't guarantee that code in VM actually
implements version Y fully and will need to check correctness per-command anyway.

Thanks

>