[1/5] virtio-net: Allow setting the MAC address via set_config
diff mbox

Message ID 1231881829.9095.191.camel@bling
State Accepted, archived
Headers show

Commit Message

Alex Williamson Jan. 13, 2009, 9:23 p.m. UTC
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

Comments

Dor Laor Jan. 14, 2009, 10:05 a.m. UTC | #1
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
Alex Williamson Jan. 14, 2009, 3:34 p.m. UTC | #2
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
Jamie Lokier Jan. 14, 2009, 4:41 p.m. UTC | #3
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
Dor Laor Jan. 14, 2009, 10:06 p.m. UTC | #4
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
Dor Laor Jan. 14, 2009, 10:08 p.m. UTC | #5
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
Paul Brook Jan. 14, 2009, 10:14 p.m. UTC | #6
> 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
Jamie Lokier Jan. 15, 2009, 1:11 p.m. UTC | #7
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
Jamie Lokier Jan. 15, 2009, 1:12 p.m. UTC | #8
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
Avi Kivity Jan. 15, 2009, 1:41 p.m. UTC | #9
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).
Dor Laor Jan. 18, 2009, 9:37 a.m. UTC | #10
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
Avi Kivity Jan. 18, 2009, 9:42 a.m. UTC | #11
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.

Patch
diff mbox

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