From: Hiroshi Shimamoto <redacted>
Add netlink directives and ndo entry to control VF multicast promiscuous mode.
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC addresses
per VF. It means that we cannot assign over 30 IPv6 addresses to a single
VF interface on VM. We want thousands IPv6 addresses in VM.
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous functionality.
Adding a new hook for this seems over-complicated to me. And it still
doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging before
we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe driver
to enable multicast promiscuous mode whenever the list grows past the
limit?
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)&msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that 30
multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
From: Hiroshi Shimamoto <redacted>
Add netlink directives and ndo entry to control VF multicast promiscuous mode.
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC addresses
per VF. It means that we cannot assign over 30 IPv6 addresses to a single
VF interface on VM. We want thousands IPv6 addresses in VM.
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous functionality.
Adding a new hook for this seems over-complicated to me. And it still
doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging before
we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe driver
to enable multicast promiscuous mode whenever the list grows past the
limit?
I had submitted a patch to change ixgbe and ixgbevf driver for this issue.
https://lkml.org/lkml/2014/11/27/269
The previous patch introduces API between ixgbe and ixgbevf driver to
enable multicast promiscuous mode, and ixgbevf enables it automatically
if the number of addresses is over than 30.
I got some comment and I would like to clarify the point, but there was no
answer.
That's the reason I submitted this patch.
Do you think a patch for the ixgbe/ixgbevf driver is preferred?
thanks,
Hiroshi
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)&msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that 30
multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
From: Hiroshi Shimamoto <redacted>
Add netlink directives and ndo entry to control VF multicast promiscuous
mode.
quoted
quoted
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC
addresses per VF. It means that we cannot assign over 30 IPv6
addresses to a single VF interface on VM. We want thousands IPv6
addresses in VM.
quoted
quoted
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous
functionality.
quoted
Adding a new hook for this seems over-complicated to me. And it still
doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging
before we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe
driver to enable multicast promiscuous mode whenever the list grows
past the limit?
I had submitted a patch to change ixgbe and ixgbevf driver for this issue.
https://lkml.org/lkml/2014/11/27/269
The previous patch introduces API between ixgbe and ixgbevf driver to
enable multicast promiscuous mode, and ixgbevf enables it automatically if
the number of addresses is over than 30.
I believe the issue is with allowing a VF to automatically enter Promiscuous Multicast without the PF's ok is concern over VM isolation. Of course that isolation, when it comes to multicast, is rather limited anyway given that our multicast filter uses only 12-bit of the address for a match. Still this (or doing it by default) would only open that up considerably more (all multicasts). I assume for your application you're not concerned, but are there other use cases that would worry about such things?
Thanks,
-Don Skidmore [off-list ref]
I got some comment and I would like to clarify the point, but there was no
answer.
That's the reason I submitted this patch.
Do you think a patch for the ixgbe/ixgbevf driver is preferred?
thanks,
Hiroshi
quoted
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)&msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that 30
multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
From: Hiroshi Shimamoto <redacted>
Add netlink directives and ndo entry to control VF multicast promiscuous
mode.
quoted
quoted
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC
addresses per VF. It means that we cannot assign over 30 IPv6
addresses to a single VF interface on VM. We want thousands IPv6
addresses in VM.
quoted
quoted
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous
functionality.
quoted
Adding a new hook for this seems over-complicated to me. And it still
doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging
before we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe
driver to enable multicast promiscuous mode whenever the list grows
past the limit?
I had submitted a patch to change ixgbe and ixgbevf driver for this issue.
https://lkml.org/lkml/2014/11/27/269
The previous patch introduces API between ixgbe and ixgbevf driver to
enable multicast promiscuous mode, and ixgbevf enables it automatically if
the number of addresses is over than 30.
I believe the issue is with allowing a VF to automatically enter Promiscuous Multicast without the PF's ok is concern
So you mean that we should take care about enabling VF multicast promiscuous mode
in host side, right? The host allows multicast promiscuous and VF requests it too,
then enables VF multicast promiscuous mode.
So, what is preferred way to do in host do you think?
over VM isolation. Of course that isolation, when it comes to multicast, is rather limited anyway given that our multicast
filter uses only 12-bit of the address for a match. Still this (or doing it by default) would only open that up considerably
more (all multicasts). I assume for your application you're not concerned, but are there other use cases that would worry
about such things?
Sorry I couldn't catch the point.
What is the issue? I think there is no difference for the users who don't want
many multicast addresses in guest. In the current implementation, overflowed
multicast addresses silently discarded in ixgbevf. I believe there is no user
who want to use over 30 multicast addresses now. If VF multicast promiscuous mode
is enabled in certain VF, the behavior of other VFs is not changed.
thanks,
Hiroshi
Thanks,
-Don Skidmore [off-list ref]
quoted
I got some comment and I would like to clarify the point, but there was no
answer.
That's the reason I submitted this patch.
Do you think a patch for the ixgbe/ixgbevf driver is preferred?
thanks,
Hiroshi
quoted
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)&msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that 30
multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
From: Hiroshi Shimamoto <redacted>
Add netlink directives and ndo entry to control VF multicast
promiscuous
mode.
quoted
quoted
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC
addresses per VF. It means that we cannot assign over 30 IPv6
addresses to a single VF interface on VM. We want thousands IPv6
addresses in VM.
quoted
quoted
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous
functionality.
quoted
Adding a new hook for this seems over-complicated to me. And it
still doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging
before we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe
driver to enable multicast promiscuous mode whenever the list
grows past the limit?
I had submitted a patch to change ixgbe and ixgbevf driver for this issue.
https://lkml.org/lkml/2014/11/27/269
The previous patch introduces API between ixgbe and ixgbevf driver
to enable multicast promiscuous mode, and ixgbevf enables it
automatically if the number of addresses is over than 30.
I believe the issue is with allowing a VF to automatically enter
Promiscuous Multicast without the PF's ok is concern
So you mean that we should take care about enabling VF multicast
promiscuous mode in host side, right? The host allows multicast promiscuous
and VF requests it too, then enables VF multicast promiscuous mode.
So, what is preferred way to do in host do you think?
I think we are saying the same thing. I believe it would be fine if the VF requests this to happen (threw a mailbox message like you set up) and the PF will do it if the systems policy has been set up that way (as you did with the control mode).
This way the behavior (related to multicast) is the same as it has been, unless the system has been setup specifically to allow VF multicast promiscuous mode.
I know it's been mentioned that this is onerous on those who want this behavior to be automatic, but I don't see how else it could be done and take account for people that are concerned about allowing a (possibly untrusted) VM promoting itself in to multicast promiscuous mode.
quoted
over VM isolation. Of course that isolation, when it comes to multicast, is
rather limited anyway given that our multicast
quoted
filter uses only 12-bit of the address for a match. Still this (or
doing it by default) would only open that up considerably more (all
multicasts). I assume for your application you're not concerned, but are
there other use cases that would worry about such things?
Sorry I couldn't catch the point.
What is the issue? I think there is no difference for the users who don't want
many multicast addresses in guest. In the current implementation,
overflowed multicast addresses silently discarded in ixgbevf. I believe there
is no user who want to use over 30 multicast addresses now. If VF multicast
promiscuous mode is enabled in certain VF, the behavior of other VFs is not
changed.
thanks,
Hiroshi
quoted
Thanks,
-Don Skidmore [off-list ref]
quoted
I got some comment and I would like to clarify the point, but there
was no answer.
That's the reason I submitted this patch.
Do you think a patch for the ixgbe/ixgbevf driver is preferred?
thanks,
Hiroshi
quoted
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)&msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that
30 multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
From: Hiroshi Shimamoto <redacted>
Add netlink directives and ndo entry to control VF multicast
promiscuous
mode.
quoted
quoted
Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC
addresses per VF. It means that we cannot assign over 30 IPv6
addresses to a single VF interface on VM. We want thousands IPv6
addresses in VM.
quoted
quoted
There is capability of multicast promiscuous mode in Intel 82599 chip.
It enables all multicast packets are delivered to the target VF.
This patch prepares to control that VF multicast promiscuous
functionality.
quoted
Adding a new hook for this seems over-complicated to me. And it
still doesn't solve the real problems that
a) the user has to know about this limit, and
b) manually configure the feature
Most of us, lacking the ability to imagine such arbitrary hardware
limitations, will go through a few hours of frustrating debugging
before we figure this one out...
Why can't the ixgbevf driver just automatically signal the ixgbe
driver to enable multicast promiscuous mode whenever the list
grows past the limit?
I had submitted a patch to change ixgbe and ixgbevf driver for this issue.
https://lkml.org/lkml/2014/11/27/269
The previous patch introduces API between ixgbe and ixgbevf driver
to enable multicast promiscuous mode, and ixgbevf enables it
automatically if the number of addresses is over than 30.
I believe the issue is with allowing a VF to automatically enter
Promiscuous Multicast without the PF's ok is concern
So you mean that we should take care about enabling VF multicast
promiscuous mode in host side, right? The host allows multicast promiscuous
and VF requests it too, then enables VF multicast promiscuous mode.
So, what is preferred way to do in host do you think?
I think we are saying the same thing. I believe it would be fine if the VF requests this to happen (threw a mailbox message
like you set up) and the PF will do it if the systems policy has been set up that way (as you did with the control mode).
This way the behavior (related to multicast) is the same as it has been, unless the system has been setup specifically
to allow VF multicast promiscuous mode.
Now I understand what you're saying.
Will make patches that make knob in host/PF and ixgbe/ixgbevf interface.
I think I should try to find whether there is a way to make the know without ndo.
I know it's been mentioned that this is onerous on those who want this behavior to be automatic, but I don't see how else
it could be done and take account for people that are concerned about allowing a (possibly untrusted) VM promoting itself
in to multicast promiscuous mode.
I didn't mind its onerousness so much.
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.
thanks,
Hiroshi
quoted
quoted
over VM isolation. Of course that isolation, when it comes to multicast, is
rather limited anyway given that our multicast
quoted
filter uses only 12-bit of the address for a match. Still this (or
doing it by default) would only open that up considerably more (all
multicasts). I assume for your application you're not concerned, but are
there other use cases that would worry about such things?
Sorry I couldn't catch the point.
What is the issue? I think there is no difference for the users who don't want
many multicast addresses in guest. In the current implementation,
overflowed multicast addresses silently discarded in ixgbevf. I believe there
is no user who want to use over 30 multicast addresses now. If VF multicast
promiscuous mode is enabled in certain VF, the behavior of other VFs is not
changed.
thanks,
Hiroshi
quoted
Thanks,
-Don Skidmore [off-list ref]
quoted
I got some comment and I would like to clarify the point, but there
was no answer.
That's the reason I submitted this patch.
Do you think a patch for the ixgbe/ixgbevf driver is preferred?
thanks,
Hiroshi
quoted
I'd also like to note that this comment in
drivers/net/ethernet/intel/ixgbevf/vf.c
indicates that the author had some ideas about how more than 30
addresses could/should be handled:
static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
struct net_device *netdev)
{
struct netdev_hw_addr *ha;
u32 msgbuf[IXGBE_VFMAILBOX_SIZE];
u16 *vector_list = (u16 *)&msgbuf[1];
u32 cnt, i;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
* msg type). That's 30 hash values if we pack 'em right. If
* there are more than 30 MC addresses to add then punt the
* extras for now and then add code to handle more than 30 later.
* It would be unusual for a server to request that many multi-cast
* addresses except for in large enterprise network environments.
*/
The last 2 lines of that comment are of course totally bogus and
pointless and should be deleted in any case... It's obvious that
30 multicast addresses is ridiculously low for lots of normal use cases.
Bjørn
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
From: David Laight <hidden> Date: 2015-01-21 11:57:57
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.
David
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.
thanks,
Hiroshi
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
My concern is what is the real issue that VF multicast promiscuous mode
can cause.
quoted
quoted
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.
quoted
quoted
I mean that we can receive all multicast addresses by an onerous
operation in untrusted VM.
quoted
quoted
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.
thanks,
Hiroshi
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
From: David Laight <hidden> Date: 2015-01-22 09:51:25
From: Skidmore, Donald C
quoted
quoted
From: Hiroshi Shimamoto
quoted
My concern is what is the real issue that VF multicast promiscuous mode
can cause.
quoted
quoted
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.
quoted
quoted
I mean that we can receive all multicast addresses by an onerous
operation in untrusted VM.
quoted
quoted
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
From: Jeff Kirsher <hidden> Date: 2015-01-22 10:52:52
On Thu, 2015-01-22 at 09:50 +0000, David Laight wrote:
From: Skidmore, Donald C
quoted
quoted
quoted
From: Hiroshi Shimamoto
quoted
My concern is what is the real issue that VF multicast
promiscuous mode
quoted
quoted
can cause.
quoted
quoted
I think there is the 4k entries to filter multicast address,
and the
quoted
quoted
quoted
quoted
current ixgbe/ixgbevf can turn all bits on from VM. That is
almost same as
quoted
quoted
enabling multicast promiscuous mode.
quoted
quoted
I mean that we can receive all multicast addresses by an
onerous
quoted
quoted
operation in untrusted VM.
quoted
quoted
I think we should clarify what is real security issue in this
context.
quoted
quoted
quoted
If you are worried about passing un-enabled multicasts to users
then
quoted
quoted
quoted
what about doing a software hash of received multicasts and
checking
quoted
quoted
quoted
against an actual list of multicasts enabled for that hash
entry.
quoted
quoted
quoted
Under normal conditions there is likely to be only a single
address to check.
quoted
quoted
quoted
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
quoted
quoted
privilege to peek every multicast packet in VM and that doesn't
look good.
quoted
quoted
On the other hand, I think that there has been the same privilege
in the
quoted
quoted
current ixgbe/ixgbevf implementation already. Or I'm reading the
code
quoted
quoted
wrongly.
I'd like to clarify what is the issue of allowing to receive all
multicast packets.
quoted
Allowing a VM to give itself the privilege of seeing every multicast
packet
quoted
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
quoted
someone specifically allowed this to happen and then must not be
concerned.
quoted
We could even log that it has occurred, which I believe your patch
did do.
quoted
The issue is also further muddied, as you mentioned above, since
some of
quoted
these multicast packets are leaking anyway (the HW currently uses a
12 bit mask).
quoted
It's just that this change would greatly enlarge that hole from a
fraction to
quoted
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?
So give an example of when the VF driver is connected directly to the
ethernet cable and a PF driver (ixgbe) does not exist, at least that is
what you are suggesting.
From: Skidmore, Donald C <hidden> Date: 2015-01-22 19:00:57
-----Original Message-----
From: David Laight [mailto:David.Laight@ACULAB.COM]
Sent: Thursday, January 22, 2015 1:50 AM
To: Skidmore, Donald C; Hiroshi Shimamoto; Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org; Choi, Sy
Jong; linux-kernel@vger.kernel.org; Hayato Momma
Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous
mode control
From: Skidmore, Donald C
quoted
quoted
quoted
From: Hiroshi Shimamoto
quoted
My concern is what is the real issue that VF multicast
promiscuous mode
can cause.
quoted
quoted
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.
quoted
quoted
I mean that we can receive all multicast addresses by an onerous
operation in untrusted VM.
quoted
quoted
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.
quoted
quoted
quoted
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.
quoted
quoted
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.
quoted
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.
quoted
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).
quoted
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?