| Message ID | 1231881829.9095.191.camel@bling (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
Alex Williamson wrote: > Rename get_config for simplicity > > Signed-off-by: Alex Williamson <alex.williamson@hp.com> > --- > > qemu/hw/virtio-net.c | 18 ++++++++++++++++-- > 1 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c > index 1f9dc16..e9b3d46 100644 > --- a/qemu/hw/virtio-net.c > +++ b/qemu/hw/virtio-net.c > @@ -42,7 +42,7 @@ static VirtIONet *to_virtio_net(VirtIODevice *vdev) > return (VirtIONet *)vdev; > } > > -static void virtio_net_update_config(VirtIODevice *vdev, uint8_t *config) > +static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config) > { > VirtIONet *n = to_virtio_net(vdev); > struct virtio_net_config netcfg; > @@ -51,6 +51,19 @@ static void virtio_net_update_config(VirtIODevice *vdev, uint8_t *config) > memcpy(config, &netcfg, sizeof(netcfg)); > } > > +static void virtio_net_set_config(VirtIODevice *vdev, const uint8_t *config) > +{ > + VirtIONet *n = to_virtio_net(vdev); > + struct virtio_net_config netcfg; > + > + memcpy(&netcfg, config, sizeof(netcfg)); > + > + if (memcmp(netcfg.mac, n->mac, 6)) { > + memcpy(n->mac, netcfg.mac, 6); > + qemu_format_nic_info_str(n->vc, n->mac); > + } > +} > + > What if the guest will chose the host's mac? Thinking about it, I don't think we should test that. A concerned host mgmt app can add ebtables roles for such a case. Maybe we can optionally allow/deny it? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2009-01-14 at 12:05 +0200, Dor Laor wrote: > Alex Williamson wrote: > > +static void virtio_net_set_config(VirtIODevice *vdev, const uint8_t *config) > > +{ > > + VirtIONet *n = to_virtio_net(vdev); > > + struct virtio_net_config netcfg; > > + > > + memcpy(&netcfg, config, sizeof(netcfg)); > > + > > + if (memcmp(netcfg.mac, n->mac, 6)) { > > + memcpy(n->mac, netcfg.mac, 6); > > + qemu_format_nic_info_str(n->vc, n->mac); > > + } > > +} > > + > > > > What if the guest will chose the host's mac? > Thinking about it, I don't think we should test that. > A concerned host mgmt app can add ebtables roles for such a case. > > Maybe we can optionally allow/deny it? What's the topology you're thinking of that the virtio-net MAC is also the host MAC? I typically use a bridge with a tap device, so the virtio-net MAC is isolated from the host. Thanks, Alex
Alex Williamson wrote: > > What if the guest will chose the host's mac? > > Thinking about it, I don't think we should test that. > > A concerned host mgmt app can add ebtables roles for such a case. > > > > Maybe we can optionally allow/deny it? > > What's the topology you're thinking of that the virtio-net MAC is also > the host MAC? I typically use a bridge with a tap device, so the > virtio-net MAC is isolated from the host. Thanks, For example you might forward IPX packets to the guest and IP/ARP to the host, using an ebtables rule to distinguish them. From the outside, it would look equivalent to a single host processing both IPX and IP. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jamie Lokier wrote: > Alex Williamson wrote: > >>> What if the guest will chose the host's mac? >>> Thinking about it, I don't think we should test that. >>> A concerned host mgmt app can add ebtables roles for such a case. >>> >>> Maybe we can optionally allow/deny it? >>> >> What's the topology you're thinking of that the virtio-net MAC is also >> the host MAC? I typically use a bridge with a tap device, so the >> virtio-net MAC is isolated from the host. Thanks, >> > > For example you might forward IPX packets to the guest and IP/ARP to > the host, using an ebtables rule to distinguish them. From the > outside, it would look equivalent to a single host processing both IPX > and IP. > > -- Jamie > > That's a nice common scenario ;) What I meant is that if we allow the guest to change his mac address, it can deliberately change it to other hosts/guests mac and thus create networking problems. Although guest can always mangle packets, maybe it worth enforcing these macs for the guest. Thanks, Dor -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jamie Lokier wrote: > Alex Williamson wrote: > >>> What if the guest will chose the host's mac? >>> Thinking about it, I don't think we should test that. >>> A concerned host mgmt app can add ebtables roles for such a case. >>> >>> Maybe we can optionally allow/deny it? >>> >> What's the topology you're thinking of that the virtio-net MAC is also >> the host MAC? I typically use a bridge with a tap device, so the >> virtio-net MAC is isolated from the host. Thanks, >> > > For example you might forward IPX packets to the guest and IP/ARP to > the host, using an ebtables rule to distinguish them. From the > outside, it would look equivalent to a single host processing both IPX > and IP. > > -- Jamie > > That's a nice common scenario ;) What I meant is that if we allow the guest to change his mac address, it can deliberately change it to other hosts/guests mac and thus create networking problems. Although guest can always mangle packets, maybe it worth enforcing these macs for the guest. Thanks, Dor -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> What I meant is that if we allow the guest to change his mac address, it > can deliberately > change it to other hosts/guests mac and thus create networking problems. > Although guest can always mangle packets, maybe it worth enforcing these > macs for the guest. This doesn't seem any different to real hardware that allows you to change the MAC address. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Brook wrote: > > What I meant is that if we allow the guest to change his mac address, it > > can deliberately > > change it to other hosts/guests mac and thus create networking problems. > > Although guest can always mangle packets, maybe it worth enforcing these > > macs for the guest. > > This doesn't seem any different to real hardware that allows you to > change the MAC address. Indeed I have used that on several occasions to workaround pointless firewalls and home networking restrictions. People doing MAC-level hot-failover in high-availability environments do it too. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dor Laor wrote: > What I meant is that if we allow the guest to change his mac address, it > can deliberately > change it to other hosts/guests mac and thus create networking problems. > Although guest can always mangle packets, maybe it worth enforcing these > macs for the guest. Although it can create network problems, sometimes it is also wanted. I think if you want to restrict the guests's ability to break the network by changing its MAC, it would be appropriate to have an option to completely lock down the MAC so the guest can't change its MAC at all. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jamie Lokier wrote: > Dor Laor wrote: > >> What I meant is that if we allow the guest to change his mac address, it >> can deliberately >> change it to other hosts/guests mac and thus create networking problems. >> Although guest can always mangle packets, maybe it worth enforcing these >> macs for the guest. >> > > Although it can create network problems, sometimes it is also wanted. > > I think if you want to restrict the guests's ability to break the > network by changing its MAC, it would be appropriate to have an option > to completely lock down the MAC so the guest can't change its MAC at all. > I don't think locking down the MAC is very useful; the guest can still fake its IP address. If the admin wants to lock down the guest, they should use netfilter (and live with the performance hit).
Jamie Lokier wrote: > Dor Laor wrote: > >> What I meant is that if we allow the guest to change his mac address, it >> can deliberately >> change it to other hosts/guests mac and thus create networking problems. >> Although guest can always mangle packets, maybe it worth enforcing these >> macs for the guest. >> > > Although it can create network problems, sometimes it is also wanted. > > I think if you want to restrict the guests's ability to break the > network by changing its MAC, it would be appropriate to have an option > to completely lock down the MAC so the guest can't change its MAC at all. > > That's what I was shooting to. One example this can be helpful is when kvm is used to run virtual servers in a computing farm like Amazon. You wouldn't like a VM owner to mess your network. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dor Laor wrote: > Jamie Lokier wrote: >> Dor Laor wrote: >> >>> What I meant is that if we allow the guest to change his mac >>> address, it can deliberately >>> change it to other hosts/guests mac and thus create networking >>> problems. >>> Although guest can always mangle packets, maybe it worth enforcing >>> these macs for the guest. >>> >> >> Although it can create network problems, sometimes it is also wanted. >> >> I think if you want to restrict the guests's ability to break the >> network by changing its MAC, it would be appropriate to have an option >> to completely lock down the MAC so the guest can't change its MAC at >> all. >> >> > That's what I was shooting to. > One example this can be helpful is when kvm is used to run virtual > servers in a computing > farm like Amazon. You wouldn't like a VM owner to mess your network. Restricting the MAC address won't help. The guest can still forge the link layer address and/or the IP layer addresses. This needs to be addressed by netfilter.
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c index 1f9dc16..e9b3d46 100644 --- a/qemu/hw/virtio-net.c +++ b/qemu/hw/virtio-net.c @@ -42,7 +42,7 @@ static VirtIONet *to_virtio_net(VirtIODevice *vdev) return (VirtIONet *)vdev; } -static void virtio_net_update_config(VirtIODevice *vdev, uint8_t *config) +static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config) { VirtIONet *n = to_virtio_net(vdev); struct virtio_net_config netcfg; @@ -51,6 +51,19 @@ static void virtio_net_update_config(VirtIODevice *vdev, uint8_t *config) memcpy(config, &netcfg, sizeof(netcfg)); } +static void virtio_net_set_config(VirtIODevice *vdev, const uint8_t *config) +{ + VirtIONet *n = to_virtio_net(vdev); + struct virtio_net_config netcfg; + + memcpy(&netcfg, config, sizeof(netcfg)); + + if (memcmp(netcfg.mac, n->mac, 6)) { + memcpy(n->mac, netcfg.mac, 6); + qemu_format_nic_info_str(n->vc, n->mac); + } +} + static uint32_t virtio_net_get_features(VirtIODevice *vdev) { uint32_t features = (1 << VIRTIO_NET_F_MAC); @@ -405,7 +418,8 @@ PCIDevice *virtio_net_init(PCIBus *bus, NICInfo *nd, int devfn) if (!n) return NULL; - n->vdev.get_config = virtio_net_update_config; + n->vdev.get_config = virtio_net_get_config; + n->vdev.set_config = virtio_net_set_config; n->vdev.get_features = virtio_net_get_features; n->vdev.set_features = virtio_net_set_features; n->rx_vq = virtio_add_queue(&n->vdev, 256, virtio_net_handle_rx);
Rename get_config for simplicity Signed-off-by: Alex Williamson <alex.williamson@hp.com> --- qemu/hw/virtio-net.c | 18 ++++++++++++++++-- 1 files changed, 16 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html