linux-kernel - RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode 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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Jan 2015 19:00:51 +0000
From:	"Skidmore, Donald C" <donald.c.skidmore@...el.com>
To:	David Laight <David.Laight@...LAB.COM>,
	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
	Bjørn Mork <bjorn@...k.no>
CC:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Choi, Sy Jong" <sy.jong.choi@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hayato Momma <h-momma@...jp.nec.com>
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
	mode control

> -----Original Message-----
> From: David Laight [mailto:David.Laight@...LAB.COM]
> Sent: Thursday, January 22, 2015 1:50 AM
> To: Skidmore, Donald C; Hiroshi Shimamoto; Bjørn Mork
> Cc: e1000-devel@...ts.sourceforge.net; netdev@...r.kernel.org; Choi, Sy
> Jong; linux-kernel@...r.kernel.org; Hayato Momma
> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
> mode control
> 
> From: Skidmore, Donald C
> > > > From: Hiroshi Shimamoto
> > > > > My concern is what is the real issue that VF multicast
> > > > > promiscuous mode
> > > can cause.
> > > > > I think there is the 4k entries to filter multicast address, and
> > > > > the current ixgbe/ixgbevf can turn all bits on from VM. That is
> > > > > almost same as
> > > enabling multicast promiscuous mode.
> > > > > I mean that we can receive all multicast addresses by an onerous
> > > operation in untrusted VM.
> > > > > I think we should clarify what is real security issue in this context.
> > > >
> > > > If you are worried about passing un-enabled multicasts to users
> > > > then what about doing a software hash of received multicasts and
> > > > checking against an actual list of multicasts enabled for that hash entry.
> > > > Under normal conditions there is likely to be only a single address to
> check.
> > > >
> > > > It may (or may not) be best to use the same hash as any hashing
> > > > hardware filter uses.
> > >
> > > thanks for the comment. But I don't think that is the point.
> > >
> > > I guess, introducing VF multicast promiscuous mode seems to add new
> > > privilege to peek every multicast packet in VM and that doesn't look
> good.
> > > On the other hand, I think that there has been the same privilege in
> > > the current ixgbe/ixgbevf implementation already. Or I'm reading the
> > > code wrongly.
> > > I'd like to clarify what is the issue of allowing to receive all multicast
> packets.
> >
> > Allowing a VM to give itself the privilege of seeing every multicast
> > packet could be seen as a hole in VM isolation.
> > Now if the host system allows this policy I don't see this as an issue
> > as someone specifically allowed this to happen and then must not be
> concerned.
> > We could even log that it has occurred, which I believe your patch did do.
> > The issue is also further muddied, as you mentioned above, since some
> > of these multicast packets are leaking anyway (the HW currently uses a 12
> bit mask).
> > It's just that this change would greatly enlarge that hole from a
> > fraction to all multicast packets.
> 
> Why does it have anything to do with VM isolation?
> Isn't is just the same as if the VM were connected directly to the ethernet
> cable?
> 
> 	David

I do see your point. :)

My hang up is more related to: without the nob to enable it (off by default) we are letting one VF dictate policy for all the other VFs and the PF.  If one VF needs to be in promiscuous multicast so is everyone else.  Their stacks now needs to deal with all the extra multicast packets.  As you point out this might not be a direct concern for isolation in that the VM could have 'chosen' to join any Multicast group and seen this traffic.  My concern over isolation is one VF has chosen that all the other VM now have to see this multicast traffic.

This will effect performance as these packets will need to be replicated.  So once again my issue is a VF is making the policy decision that doing this is ok for the entire system.  That should be the PF's job.

Does this give you a better idea where my concerns lay?