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
| ||
|
Message-ID: <uidej33c7o5gudvdvq2ggultubangijsuwyl53cmhd2jqrdxbg@2plf2qy4vyqy> Date: Fri, 20 Oct 2023 09:23:31 +0200 From: Stefano Garzarella <sgarzare@...hat.com> To: Alexandru Matei <alexandru.matei@...ath.com> Cc: Stefan Hajnoczi <stefanha@...hat.com>, "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, kvm@...r.kernel.org, virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Mihai Petrisor <mihai.petrisor@...ath.com>, Viorel Canja <viorel.canja@...ath.com> Subject: Re: [PATCH] vsock: initialize the_virtio_vsock before using VQs On Fri, Oct 20, 2023 at 12:12:04AM +0300, Alexandru Matei wrote: >On 10/19/2023 11:54 AM, Stefano Garzarella wrote: >> On Wed, Oct 18, 2023 at 09:32:47PM +0300, Alexandru Matei wrote: >>> Once VQs are filled with empty buffers and we kick the host, it can send >>> connection requests. If 'the_virtio_vsock' is not initialized before, >>> replies are silently dropped and do not reach the host. >> >> Are replies really dropped or we just miss the notification? >> >> Could the reverse now happen, i.e., the guest wants to send a connection request, finds the pointer assigned but can't use virtqueues because they haven't been initialized yet? >> >> Perhaps to avoid your problem, we could just queue vsock->rx_work at the bottom of the probe to see if anything was queued in the meantime. >> >> Nit: please use "vsock/virtio" to point out that this problem is of the virtio transport. >> >> Thanks, >> Stefano > >The replies are dropped , the scenario goes like this: > > Once rx_run is set to true and rx queue is filled with empty buffers, the host sends a connection request. Oh, I see now, I thought virtio_transport_rx_work() returned early if 'the_virtio_vsock' was not set. > The request is processed in virtio_transport_recv_pkt(), and since there is no bound socket, it calls virtio_transport_reset_no_sock() which tries to send a reset packet. > In virtio_transport_send_pkt() it checks 'the_virtio_vsock' and because it is null it exits with -ENODEV, basically dropping the packet. > >I looked on your scenario and there is an issue from the moment we set the_virtio_vsock (in this patch) up until vsock->tx_run is set to TRUE. >virtio_transport_send_pkt() will queue the packet, but virtio_transport_send_pkt_work() will exit because tx_run is FALSE. This could be fixed by moving rcu_assign_pointer() after tx_run is set to TRUE. >virtio_transport_cancel_pkt() uses the rx virtqueue once the_virtio_vsock is set, so rcu_assign_pointer() should be moved after virtio_find_vqs() is called. > >I think the way to go is to split virtio_vsock_vqs_init() in two: >virtio_vsock_vqs_init() and virtio_vsock_vqs_fill(), as Vadim >suggested. This should fix all the cases: Yep, LGTM! Thank you both for the fix, please send a v2 with this approach! Stefano > >--- > net/vmw_vsock/virtio_transport.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > >diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c >index ad64f403536a..1f95f98ddd3f 100644 >--- a/net/vmw_vsock/virtio_transport.c >+++ b/net/vmw_vsock/virtio_transport.c >@@ -594,6 +594,11 @@ static int virtio_vsock_vqs_init(struct virtio_vsock *vsock) > vsock->tx_run = true; > mutex_unlock(&vsock->tx_lock); > >+ return 0; >+} >+ >+static void virtio_vsock_vqs_fill(struct virtio_vsock *vsock) >+{ > mutex_lock(&vsock->rx_lock); > virtio_vsock_rx_fill(vsock); > vsock->rx_run = true; >@@ -603,8 +608,6 @@ static int virtio_vsock_vqs_init(struct virtio_vsock *vsock) > virtio_vsock_event_fill(vsock); > vsock->event_run = true; > mutex_unlock(&vsock->event_lock); >- >- return 0; > } > > static void virtio_vsock_vqs_del(struct virtio_vsock *vsock) >@@ -707,6 +710,7 @@ static int virtio_vsock_probe(struct virtio_device *vdev) > goto out; > > rcu_assign_pointer(the_virtio_vsock, vsock); >+ virtio_vsock_vqs_fill(vsock); > > mutex_unlock(&the_virtio_vsock_mutex); > >@@ -779,6 +783,7 @@ static int virtio_vsock_restore(struct virtio_device *vdev) > goto out; > > rcu_assign_pointer(the_virtio_vsock, vsock); >+ virtio_vsock_vqs_fill(vsock); > > out: > mutex_unlock(&the_virtio_vsock_mutex); >-- >
Powered by blists - more mailing lists