All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Dan Carpenter <error27@gmail.com>,
	harshit.m.mogalapalli@gmail.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Xie Yongji <xieyongji@bytedance.com>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	Gautam Dawar <gautam.dawar@xilinx.com>,
	Eli Cohen <elic@nvidia.com>
Subject: Re: [PATCH v2] vduse: Validate vq_num in vduse_validate_config()
Date: Mon, 28 Nov 2022 08:10:09 -0500	[thread overview]
Message-ID: <20221128070238-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20221128111310.6exrqi26grwspqcz@sgarzare-redhat>

On Mon, Nov 28, 2022 at 12:13:10PM +0100, Stefano Garzarella wrote:
> On Mon, Nov 28, 2022 at 01:58:00PM +0300, Dan Carpenter wrote:
> > On Mon, Nov 28, 2022 at 11:53:12AM +0100, Stefano Garzarella wrote:
> > > On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote:
> > > > Add a limit to 'config->vq_num' which is user controlled data which
> > > > comes from an vduse_ioctl to prevent large memory allocations.
> > > >
> > > > This is found using static analysis with smatch.
> > > >
> > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
> > > > ---
> > > > v1->v2: Change title of the commit and description, add a limit to
> > > > 	vq_num.
> > > >
> > > > Note: I think here 0xffff is the max size of vring =  no: of vqueues.
> > > > Only compile and boot tested.
> > > > ---
> > > > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > index 35dceee3ed56..31017ebc4d7c 100644
> > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config)
> > > > 	if (config->config_size > PAGE_SIZE)
> > > > 		return false;
> > > >
> > > > +	if (config->vq_num > 0xffff)
> > > 
> > > What about using U16_MAX here?
> > 
> > Where is the ->vq_num stored in a u16?  I looked for this but didn't
> > see it.
> 
> I thought vq_num referred to the number of elements in the vq (like
> .get_vq_num_max), since this patch wants to limit to 0xffff.
> 
> But it actually refers to the number of virtqueue, so @Harshit why do we
> limit it to 0xffff?
> 
> Maybe we should explain it in the commit message or in a comment.
> 
> Thanks,
> Stefano

This limit is somewhat arbitrary.
However, currently virtio pci and ccw are limited to a 16 bit vq number.
While MMIO isn't it is also isn't used with lots of VQs due to
current lack of support for per-vq interrupts.
Thus, the 0xffff limit on number of VQs corresponding
to a 16-bit VQ number seems sufficient for now.

Feel free to put the above in a code comment.

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Dan Carpenter <error27@gmail.com>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>,
	harshit.m.mogalapalli@gmail.com, Jason Wang <jasowang@redhat.com>,
	Xie Yongji <xieyongji@bytedance.com>,
	Gautam Dawar <gautam.dawar@xilinx.com>,
	Parav Pandit <parav@nvidia.com>, Eli Cohen <elic@nvidia.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] vduse: Validate vq_num in vduse_validate_config()
Date: Mon, 28 Nov 2022 08:10:09 -0500	[thread overview]
Message-ID: <20221128070238-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20221128111310.6exrqi26grwspqcz@sgarzare-redhat>

On Mon, Nov 28, 2022 at 12:13:10PM +0100, Stefano Garzarella wrote:
> On Mon, Nov 28, 2022 at 01:58:00PM +0300, Dan Carpenter wrote:
> > On Mon, Nov 28, 2022 at 11:53:12AM +0100, Stefano Garzarella wrote:
> > > On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote:
> > > > Add a limit to 'config->vq_num' which is user controlled data which
> > > > comes from an vduse_ioctl to prevent large memory allocations.
> > > >
> > > > This is found using static analysis with smatch.
> > > >
> > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> > > > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
> > > > ---
> > > > v1->v2: Change title of the commit and description, add a limit to
> > > > 	vq_num.
> > > >
> > > > Note: I think here 0xffff is the max size of vring =  no: of vqueues.
> > > > Only compile and boot tested.
> > > > ---
> > > > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > index 35dceee3ed56..31017ebc4d7c 100644
> > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config)
> > > > 	if (config->config_size > PAGE_SIZE)
> > > > 		return false;
> > > >
> > > > +	if (config->vq_num > 0xffff)
> > > 
> > > What about using U16_MAX here?
> > 
> > Where is the ->vq_num stored in a u16?  I looked for this but didn't
> > see it.
> 
> I thought vq_num referred to the number of elements in the vq (like
> .get_vq_num_max), since this patch wants to limit to 0xffff.
> 
> But it actually refers to the number of virtqueue, so @Harshit why do we
> limit it to 0xffff?
> 
> Maybe we should explain it in the commit message or in a comment.
> 
> Thanks,
> Stefano

This limit is somewhat arbitrary.
However, currently virtio pci and ccw are limited to a 16 bit vq number.
While MMIO isn't it is also isn't used with lots of VQs due to
current lack of support for per-vq interrupts.
Thus, the 0xffff limit on number of VQs corresponding
to a 16-bit VQ number seems sufficient for now.

Feel free to put the above in a code comment.

-- 
MST


  parent reply	other threads:[~2022-11-28 13:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28  8:36 [PATCH v2] vduse: Validate vq_num in vduse_validate_config() Harshit Mogalapalli
2022-11-28 10:53 ` Stefano Garzarella
2022-11-28 10:53   ` Stefano Garzarella
2022-11-28 10:58   ` Dan Carpenter
2022-11-28 10:58     ` Dan Carpenter
2022-11-28 11:13     ` Stefano Garzarella
2022-11-28 11:13       ` Stefano Garzarella
2022-11-28 12:35       ` Harshit Mogalapalli
2022-11-28 13:10       ` Michael S. Tsirkin [this message]
2022-11-28 13:10         ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221128070238-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=elic@nvidia.com \
    --cc=error27@gmail.com \
    --cc=gautam.dawar@xilinx.com \
    --cc=harshit.m.mogalapalli@gmail.com \
    --cc=harshit.m.mogalapalli@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sgarzare@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xieyongji@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.