linux-kernel - Re: [RFC 1/2] virtio_net: timeout control virtqueue commands

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] [day] [month] [year] [list]

Message-ID: <CAJaqyWeDcyKKOvVdqUkpTuH3d-Tb9rBHG3ym+LC0fcmhrN_FJA@mail.gmail.com>
Date: Wed, 22 Oct 2025 14:55:18 +0200
From: Eugenio Perez Martin <eperezma@...hat.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Maxime Coquelin <mcoqueli@...hat.com>, Yongji Xie <xieyongji@...edance.com>, 
	virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Dragos Tatulea DE <dtatulea@...dia.com>, jasowang@...hat.com
Subject: Re: [RFC 1/2] virtio_net: timeout control virtqueue commands

On Wed, Oct 22, 2025 at 1:43 PM Michael S. Tsirkin <mst@...hat.com> wrote:
>
> On Wed, Oct 22, 2025 at 12:50:53PM +0200, Eugenio Perez Martin wrote:
> > Let me switch to MQ as I think it illustrates the point better.
> >
> > IIUC the workflow:
> > a) virtio-net sends MQ_VQ_PAIRS_SET 2 to the device
> > b) VDUSE CVQ sends ok to the virtio-net driver
> > c) VDUSE CVQ sends the command to the VDUSE device
> > d) Now the virtio-net driver sends virtio-net sends MQ_VQ_PAIRS_SET 1
> > e) VDUSE CVQ sends ok to the virtio-net driver
> >
> > The device didn't process the MQ_VQ_PAIRS_SET 1 command at this point,
> > so it potentially uses the second rx queue. But, by the standard:
> >
> > The device MUST NOT queue packets on receive queues greater than
> > virtqueue_pairs once it has placed the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET
> > command in a used buffer.
> >
> > So the driver does not expect rx buffers on that queue at all. From
> > the driver's POV, the device is invalid, and it could mark it as
> > broken.
>
> ok intresting. Note that if userspace processes vqs it should process
> cvq too. I don't know what to do in this case yet, I'm going on
> vacation, let me ponder this a bit.
>

Sure.

>
> > And, what's worse, how to handle it if the device now replies with
> > VIRTIO_NET_ERR to the VDUSE CVQ?
>
> this part does not bother me much. break it, probably.
>

To "successfully break it" we should implement NEED_RESET, or would it
work to just stop forwarding messages?

> > > > If we wait for the device to reply, we're in the
> > > > same situation regarding the RTNL.
> > > >
> > > > Now we receive a new state (A, B, E). We haven't sent the (A, B, D),
> > > > so it is good to just replace the (A, B, D) with that. and send it
> > > > when (A, B, C) is completed with either success or failure.
> > > >
> > > > 2) VQ_PAIRS_SET
> > > >
> > > > The driver starts with 1 vq pair. Now the driver sets 3 vq pairs, and
> > > > the VDUSE CVQ forwards the command. The driver still thinks that it is
> > > > using 1 vq pair. I can store that the driver request was 3, and it is
> > > > still in-flight. Now the timeout occurs, so the VDUSE device returns
> > > > fail to the driver, and the driver frees the vq regions etc. After
> > > > that, the device now replies OK. The memory that was sent as the new
> > > > vqs avail ring and descriptor ring now contains garbage, and it could
> > > > happen that the device start overriding unrelated memory.
> > > >
> > > > Not even VQ_RESET protects against it as there is still a window
> > > > between the CMD set and the VQ reset.
> > >
> > > Timeouts should be up to userspace. If userspace times out
> > > and then gets confused, kernel is not to blame.
> > >
> > >
> >
> > I meant the virtio-net driver will be confused.
>