Messages in this thread | | | Subject | Re: [PATCH] vdpa/mlx5: fix param validation in mlx5_vdpa_get_config() | From | Jason Wang <> | Date | Thu, 18 Feb 2021 13:47:24 +0800 |
| |
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@vger.kernel.org >>> > > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> >>> > > --- >>> > > 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 >
| |