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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 25 Nov 2021 11:40:46 +0100
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     "Wang, Wei W" <wei.w.wang@...el.com>
Cc:     "mst@...hat.com" <mst@...hat.com>,
        "stefanha@...hat.com" <stefanha@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "asias@...hat.com" <asias@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH] virtio/vsock: fix the transport to work with
 VMADDR_CID_ANY

On Thu, Nov 25, 2021 at 09:27:40AM +0000, Wang, Wei W wrote:
>On Thursday, November 25, 2021 3:16 PM, Wang, Wei W wrote:
>> -	/* Update CID in case it has changed after a transport reset event */
>> -	vsk->local_addr.svm_cid = dst.svm_cid;
>> -
>>  	if (space_available)
>>  		sk->sk_write_space(sk);
>>
>
>Not sure if anybody knows how this affects the transport reset.

I believe the primary use case is when a guest is migrated.

After the migration, the transport gets a reset event from the 
hypervisor and all connected sockets are closed. The ones in listen 
remain open though.

Also the guest's CID may have changed after migration. So if an 
application has open listening sockets, bound to the old CID, this 
should ensure that the socket continues to be usable.

The patch would then change this behavior.

So maybe to avoid problems, we could update the CID only if it is 
different from VMADDR_CID_ANY:

	if (vsk->local_addr.svm_cid != VMADDR_CID_ANY)
		vsk->local_addr.svm_cid = dst.svm_cid;


When this code was written, a guest only supported a single transport, 
so it could only have one CID assigned, so that wasn't a problem.
For that reason I'll add this Fixes tag:
Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")

Thanks,
Stefano

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ