netdev - Re: [PATCH v2 0/3] VSOCK: vsockmon virtual device to monitor AF

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: <8fab775d-6440-2669-72f5-cf46bf88ce27@deic.uab.cat>
Date:   Mon, 5 Sep 2016 12:22:01 +0200
From:   Gerard Garcia <ggarcia@...a.uab.cat>
To:     Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v2 0/3] VSOCK: vsockmon virtual device to monitor AF_VSOCK
 sockets.

On 08/22/2016 12:48 PM, Gerard Garcia wrote:
> On 08/15/2016 05:13 PM, Stefan Hajnoczi wrote:
>> On Mon, Aug 15, 2016 at 02:15:38AM +0300, Michael S. Tsirkin wrote:
>>> On Sat, Aug 13, 2016 at 12:21:51PM +0200, ggarcia@...a.uab.cat wrote:
>>>> From: Gerard Garcia <ggarcia@...c.uab.cat>
>>>>
>>>> This patch applies over the mst vhost git repository:
>>>> http://git.kernel.org/cgit/linux/kernel/git/mst/vhost.git
>>>
>>> So I do like where this is going, but it gives me pause
>>> that there's a global list of taps, where all sockets
>>> seem to multicast to them all.
>>>
>>> In particular, this won't play well with things
>>> like containers.
>>
>> vsock currently has no network namespace support.  I agree that the tap
>> instances should be per-namespace when we add namespace support.
>>
>>> As each socket is bound to a physical device, how about binding
>>> the monitor there as well?
>>
>> Sockets aren't bound to physical devices, they are bound globally in the
>> af_vsock.ko module.  The module currently doesn't allow multiple
>> instances (you cannot have multiple VMCI or virtio transports).
>>
>>> Only sockets from this device
>>> would do the forwarding, and only one monitor per
>>> device would be supported.
>>>
>>> In a sense this will make it more like macvtap than tap.
>>
>> Restricting the number of monitors could make userspace cumbersome.
>> Imagine two scripts that want to capture packets.  The two scripts have
>> no knowledge of each other and create their own vsockmon interfaces.  If
>> we restrict vsockmon to just 1 interface then users need to agree on
>> sharing just 1 vsockmon interface.  I don't think this is beneficial.
>>
>> So I think this global list is acceptable until we introduce network
>> namespace support.  At that point it will become per-namespace.
>>
>
> Sorry, I was out last week.
>
> I don't have much to add to what Stefan said. I agree that when vsock
> introduces namespace support it will be necessary to have monitors
> divided per-namespace. Right now, if only one af_vsock instance is
> allowed, I think it makes sense to have a global list of taps.
>
> Gerard

Sorry to insist Michael, but do you agree with us? or do you think it is 
better to follow a different approach?