linux-kernel - Re: [PATCH][RFC] net/bridge: add basic VEPA support

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:	Wed, 12 Aug 2009 15:19:36 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Paul Congdon \(UC Davis\)" <ptcongdon@...avis.edu>
Cc:	"'Fischer, Anna'" <anna.fischer@...com>,
	"'Stephen Hemminger'" <shemminger@...ux-foundation.org>,
	bridge@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org,
	evb@...oogroups.com, davem@...emloft.net, kaber@...sh.net,
	adobriyan@...il.com, "'Eric Biederman'" <ebiederm@...ssion.com>
Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support

On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
> > >
> > > The patch from Eric Biederman to allow macvlan to bridge between
> > > its slave ports is at
> > >
> > > http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
> > 
> > Looking through the discussions here, it does not seem as if a decision
> > was made to integrate those patches, because they would make the
> > macvlan interface behave too much like a bridge. 

Right, that question is still open, and dont't see it as very important
right now, as long as we can still use it for VEPA.

> > Also, it seems as if there was still a problem with doing
> > multicast/broadcast delivery when enabling local VM-to-VM
> > communication. Is that solved by now?

Not yet, but I guess it comes as a natural extension when I fix
multicast/broadcast delivery from the reflective relay for VEPA.

The logic that I would use there is:

broadcast from a dowstream port:
     if (bridge_mode(source_port)) {
          forward_to_upstream(frame);
          for_each_downstream(port) {
                /* deliver to all bridge ports except self, do
                   not deliver to any VEPA port. */
                if (bridge_mode(port) && port != source_port) {
                       forward_to_downstream(frame, port);
                }
          }
     } else {
          forward_to_upstream(frame);
     }


broadcast from the upstream port
     if (bridge_mode(frame.source)) {
          /* comes from a port in bridge mode, so has already been
             delivered to all other bridge ports */
          for_each_downstream(port) {
                if (!bridge_mode(port)) {
                         forward_to_downstream(frame, port);
                }
          }
     } else if (vepa_mode(frame.source)) {
          /* comes from VEPA port, so need to deliver to all
             bridge and all vepa ports except self */
          for_each_downstream(port) {
                if (port != frame.source)
                       forward_to_downstream(frame, port);
     } else {
          /* external source, so flood to everyone */
          for_each_downstream(port) {
                forward_to_downstream(frame, port);
     }

For multicast, we can do the same, or optionally add a per-port filter
as you mentioned, if it becomes a bottleneck. 

Do you think this addresses the problem, or did I miss something important?

> Also, is there a solution, or plans for a solution, to address macvtap
> interfaces that are set to 'promiscuous' mode?  It would seem fairly easy to
> support this for interfaces that are simply trying to listen to the port
> (e.g. Wireshark). 

If you want to use tcpdump or wireshark on all ports simulateously in a pure
VEPA, you can still attach it to the 'lowerdev', e.g. eth0 or eth0.2 (for macvlan
nested in vlan).
If we allow bridge ports, we might want to extend the local delivery
to also go through all the hooks of the external port, so that you can
attach packet sockets there.

> If the port was being used by something like a firewall
> then the VEPA filtering doesn't work too well.

Not sure what you mean. Are you talking about a firewall separating the guests
from the outside, between the VEPA and the reflective relay, or a firewall between
the guests in case of local delivery?

	Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/