Re: [PATCH] vdpa/mlx5: fix param validation in mlx5_vdpa_get_config()

[Jason Wang]

On 2021/2/10 下午6:08, Stefano Garzarella wrote:
> On Tue, Feb 09, 2021 at 04:31:23AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Feb 09, 2021 at 11:24:03AM +0800, Jason Wang wrote:
> > > On 2021/2/9 上午2:38, Michael S. Tsirkin wrote:
> > > > On Mon, Feb 08, 2021 at 05:17:41PM +0100, Stefano Garzarella wrote:
> > > > > It's legal to have 'offset + len' equal to
> > > > > sizeof(struct virtio_net_config), since 'ndev->config' is a
> > > > > 'struct virtio_net_config', so we can safely copy its content under
> > > > > this condition.
> > > > >
> > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported 
> > > mlx5 devices")
> > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > > Signed-off-by: Stefano Garzarella <sgarzare@xxxxxxxxxx>
> > > > > ---
> > > > >   drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > index dc88559a8d49..10e9b09932eb 100644
> > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > @@ -1820,7 +1820,7 @@ static void mlx5_vdpa_get_config(struct 
> > > vdpa_device *vdev, unsigned int offset,
> > > > >       struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > > > >       struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > > -    if (offset + len < sizeof(struct virtio_net_config))
> > > > > +    if (offset + len <= sizeof(struct virtio_net_config))
> > > > >           memcpy(buf, (u8 *)&ndev->config + offset, len);
> > > > >   }
> > > > Actually first I am not sure we need these checks at all.
> > > > vhost_vdpa_config_validate already validates the values, right?
> > >
> > >
> > > I think they're working at different levels. There's no guarantee that
> > > vhost-vdpa is the driver for this vdpa device.
> >
> > In fact, get_config returns void, so userspace can easily get
> > trash if it passes incorrect parameters by mistake, there is
> > no way for userspace to find out whether that is the case :(
> >
> > Any objections to returning the # of bytes copied, or -1
> > on error?
>
> Make sense for me, but are we sure we don't break userspace if we 
> return the number of bytes instead of 0 on success?
>
> I had a quick look at QEMU and it looks like we consider success if 
> the return value is >= 0, but I need to check further.


So I think in the vdpa bus level, we can return #bytes and in vhost uAPI 
level, we can return error if the size is not expected otherwise zero?

Thanks


> > > >
> > > > Second, what will happen when we extend the struct and then
> > > > run new userspace on an old kernel? Looks like it will just
> > > > fail right? So what is the plan?
> > >
> > >
> > > In this case, get_config() should match the spec behaviour. That is 
> > > to say
> > > the size of config space depends on the feature negotiated.
> > >
> > > Thanks
> >
> > Yes but spec says config space can be bigger than specified by features:
> >
> >     Drivers MUST NOT limit structure size and device configuration 
> > space size. Instead, drivers SHOULD only
> >     check that device configuration space is large enough to contain 
> > the fields necessary for device operation.
>
> So IIUC in the driver we should copy as much as we can.
>
> If you agree, I can send an RFC series and we can continue the 
> discussion on it, but I think we should queue this patch for stable 
> branches.
>
> Thanks,
> Stefano