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  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, 3 Dec 2020 09:51:34 +0100
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     "Paraschiv, Andra-Irina" <andraprs@...zon.com>
Cc:     netdev <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        David Duncan <davdunc@...zon.com>,
        Dexuan Cui <decui@...rosoft.com>,
        Alexander Graf <graf@...zon.de>,
        Jorgen Hansen <jhansen@...are.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH net-next v1 0/3] vsock: Add flag field in the vsock
 address

On Wed, Dec 02, 2020 at 06:18:15PM +0200, Paraschiv, Andra-Irina wrote:
>
>
>On 02/12/2020 15:37, Stefano Garzarella wrote:
>>
>>Hi Andra,
>>
>>On Tue, Dec 01, 2020 at 05:25:02PM +0200, Andra Paraschiv wrote:
>>>vsock enables communication between virtual machines and the host 
>>>they are
>>>running on. Nested VMs can be setup to use vsock channels, as the multi
>>>transport support has been available in the mainline since the 
>>>v5.5 Linux kernel
>>>has been released.
>>>
>>>Implicitly, if no host->guest vsock transport is loaded, all the 
>>>vsock packets
>>>are forwarded to the host. This behavior can be used to setup 
>>>communication
>>>channels between sibling VMs that are running on the same host. 
>>>One example can
>>>be the vsock channels that can be established within AWS Nitro Enclaves
>>>(see Documentation/virt/ne_overview.rst).
>>>
>>>To be able to explicitly mark a connection as being used for a 
>>>certain use case,
>>>add a flag field in the vsock address data structure. The 
>>>"svm_reserved1" field
>>>has been repurposed to be the flag field. The value of the flag 
>>>will then be
>>>taken into consideration when the vsock transport is assigned.
>>>
>>>This way can distinguish between nested VMs / local communication 
>>>and sibling
>>>VMs use cases. And can also setup one or more types of 
>>>communication at the same
>>>time.
>>>
>>
>>Another thing worth mentioning is that for now it is not supported in
>>vhost-vsock, since we are discarding every packet not addressed to the
>>host.
>
>Right, thanks for the follow-up.
>
>>
>>What we should do would be:
>>- add a new IOCTL to vhost-vsock to enable sibling communication, by
>>  default I'd like to leave it disabled
>>
>>- allow sibling forwarding only if both guests have sibling
>>  communication enabled and we should implement some kind of filtering
>>  or network namespace support to allow the communication only between a
>>  subset of VMs
>>
>>
>>Do you have plans to work on it?
>
>Nope, not yet. But I can take some time in the second part of December 
>/ beginning of January for this. And we can catch up in the meantime 
>if there is something blocking or more clarifications are needed to 
>make it work.
>

Good, it will be great!

Thanks,
Stefano

Powered by blists - more mailing lists