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, 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

Powered by blists - more mailing lists