netdev - Re: Multicast and receive filtering in TUN/TAP

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]

Message-Id: <200807101029.17121.borntraeger@de.ibm.com>
Date:	Thu, 10 Jul 2008 10:29:17 +0200
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	virtualization@...ts.linux-foundation.org
Cc:	Max Krasnyansky <maxk@...lcomm.com>,
	Brian Braunstein <linuxkernel@...style.com>,
	Shaun Jackman <sjackman@...il.com>, netdev@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: Multicast and receive filtering in TUN/TAP

Am Donnerstag, 10. Juli 2008 schrieb Max Krasnyansky:
[...]
> The second question is do you guys think that QEMU/KVM/LGUEST/etc would 
> benefit if receive filtering was done by the host OS. Here is a specific 
> example of what I'm talking about.
> We can do what qemu/hw/e1000.c:receive_filter() does in the _host_ 
> context (that function currently runs in the guest context). By looking 
> at libvirt, typical QEMU based setup is that you have a single bridge 
> and all the TAPs from different VMs are hooked up to that bridge. What 
> that means is that if one VM is getting MC traffic or when the bridge 
> sees MACADDR that is not in its tables the packets get delivered to all 
> the VMs. ie We have to wake all of the up only to so that they could 
> drop that packet. Instead, we could setup filters in the host's side of 
> the TAP device.
> Does that sound like something useful for QEMU/KVM ?
> If yes we can talk about the API. If not then I'll just nuke it.

Max,

I know that on s390 the shared OSA network card have multicast filter 
capabilities. So I guess it is worthwile for a virtualization environments 
with lots of guests. I also think, that this kind of filtering should be 
straightforward to implement with the qemu e1000 code. Qemu already knows the 
multicast addresses.

Thing is, we are heading towards virtio. Unfortunately, virtio_net currently 
does not offer a method to register multicast addresses.

Rusty, do you think its worthwile to notify the host about registered 
multicast addresses?

Christian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html