netdev - Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for multicast control

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: <1441274199.26292.324.camel@citrix.com>
Date:	Thu, 3 Sep 2015 10:56:39 +0100
From:	Ian Campbell <ian.campbell@...rix.com>
To:	Paul Durrant <Paul.Durrant@...rix.com>,
	Jan Beulich <JBeulich@...e.com>
CC:	Wei Liu <wei.liu2@...rix.com>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support for
 multicast control

On Thu, 2015-09-03 at 10:34 +0100, Paul Durrant wrote:
> > 
> > -----Original Message-----
> > From: Ian Campbell [mailto:ian.campbell@...rix.com]
> > Sent: 03 September 2015 10:31
> > To: Paul Durrant; Jan Beulich
> > Cc: Wei Liu; xen-devel@...ts.xenproject.org; netdev@...r.kernel.org
> > Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add support 
> > for
> > multicast control
> > 
> > On Thu, 2015-09-03 at 10:00 +0100, Paul Durrant wrote:
> > > > 
> > > > -----Original Message-----
> > > > From: Jan Beulich [mailto:JBeulich@...e.com]
> > > > Sent: 03 September 2015 09:57
> > > > To: Paul Durrant
> > > > Cc: Ian Campbell; Wei Liu; xen-devel@...ts.xenproject.org;
> > > > netdev@...r.kernel.org
> > > > Subject: Re: [Xen-devel] [PATCH v2 net-next] xen-netback: add 
> > > > support
> > > > for
> > > > multicast control
> > > > 
> > > > > > > On 02.09.15 at 18:58, <paul.durrant@...rix.com> wrote:
> > > > > @@ -1215,6 +1289,31 @@ static void xenvif_tx_build_gops(struct
> > > > xenvif_queue *queue,
> > > > >  				break;
> > > > >  		}
> > > > > 
> > > > > +		if (extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 
> > > > > 1].type)
> > > > > {
> > > > > +			struct xen_netif_extra_info *extra;
> > > > > +
> > > > > +			extra =
> > > > &extras[XEN_NETIF_EXTRA_TYPE_MCAST_ADD - 1];
> > > > > +			ret = xenvif_mcast_add(queue->vif, extra
> > > > > -
> > > > > u.mcast.addr);
> > > > 
> > > > What's the reason this call isn't gated on vif->multicast_control?
> > > > 
> > > 
> > > No particular reason. I guess it eats a small amount of memory for no
> > > gain but a well behaved frontend wouldn't send such a request and a
> > > malicious one can only send 64 of them before netback starts to 
> > > reject
> > > them.
> > 
> > Perhaps a confused guest might submit them thinking they would work
> > when
> > actually the feature hasn't been properly negotiated and since it would
> > succeed it wouldn't generate an error on the guest side?
> 
> It would, but that's essentially harmless to functionality. If the 
> feature had not been negotiated properly then multicast flooding would 
> still be in operation so the guest would not lose any multicasts. I can 
> tighten things up if you like but as you say below it is a bit of a 
> corner case.

Ah yes, I had something backwards and thought the guest might miss out on
something it was expecting, but as you say it will just get more than it
wanted.

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