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: <CACGkMEvxMuowCxxJHNVYr=Ro4cvYs3D3VD0+Ds+4EgD1s53Gcg@mail.gmail.com>
Date: Wed, 17 Jul 2024 09:25:39 +0800
From: Jason Wang <jasowang@...hat.com>
To: Cindy Lu <lulu@...hat.com>
Cc: dtatulea@...dia.com, mst@...hat.com, parav@...dia.com, 
	netdev@...r.kernel.org, qemu-devel@...gnu.org
Subject: Re: [RFC v2] virtio-net: check the mac address for vdpa device

On Tue, Jul 16, 2024 at 2:09 PM Cindy Lu <lulu@...hat.com> wrote:
>
> On Tue, 16 Jul 2024 at 13:37, Jason Wang <jasowang@...hat.com> wrote:
> >
> > On Tue, Jul 16, 2024 at 9:14 AM Cindy Lu <lulu@...hat.com> wrote:
> > >
> > > When using a VDPA device, it is important to ensure that the MAC address
> > > in the hardware matches the MAC address from the QEMU command line.
> > >
> > > There are only two acceptable situations:
> > > 1. The hardware MAC address is the same as the MAC address specified in the QEMU
> > > command line, and both MAC addresses are not 0.
> > > 2. The hardware MAC address is not 0, and the MAC address in the QEMU command line is 0.
> > > In this situation, the hardware MAC address will overwrite the QEMU command line address.
> >
> > If this patch tries to do the above two, I'd suggest splitting it into
> > two patches.
> >
> This code is very simple. So I have put these two into one function.
> thanks

Better to split no matter how simple it is if there are two issues.

Btw, it's better to tell what kind of setup has been tested by this,
and do we need a fix tag here as well? (Or is this needed by -stable?)

> cindy
> > >
> > > Signed-off-by: Cindy Lu <lulu@...hat.com>
> > > ---
> > >  hw/net/virtio-net.c | 43 +++++++++++++++++++++++++++++++++++++------
> > >  1 file changed, 37 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > index 9c7e85caea..8f79785f59 100644
> > > --- a/hw/net/virtio-net.c
> > > +++ b/hw/net/virtio-net.c
> > > @@ -178,8 +178,8 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
> > >           * correctly elsewhere - just not reported by the device.
> > >           */
> > >          if (memcmp(&netcfg.mac, &zero, sizeof(zero)) == 0) {
> > > -            info_report("Zero hardware mac address detected. Ignoring.");
> > > -            memcpy(netcfg.mac, n->mac, ETH_ALEN);
> > > +          error_report("Zero hardware mac address detected in vdpa device. "
> > > +                       "please check the vdpa device!");
> >
> > I had two questions:
> >
> > 1) any reason to do this check while the guest is running?
> > 2) I think we need a workaround for this, unless I miss something.
> >
> this is a code change to adjust the new fix. If the mac address is 0
> the guest should fail
> to load. Maybe I can just assert fail here?

I mean get_config is usually called during VM running. It's not good
to assert here and can we move the check to realize or other place
before the VM is running?

> Thanks
> cindy
> > >          }
> > >
> > >          netcfg.status |= virtio_tswap16(vdev,
> > > @@ -3579,12 +3579,42 @@ static bool failover_hide_primary_device(DeviceListener *listener,
> > >      /* failover_primary_hidden is set during feature negotiation */
> > >      return qatomic_read(&n->failover_primary_hidden);
> > >  }
> > > +static bool virtio_net_check_vdpa_mac(NetClientState *nc, VirtIONet *n,
> > > +                                      MACAddr *cmdline_mac, Error **errp) {
> > > +  struct virtio_net_config hwcfg = {};
> > > +  static const MACAddr zero = {.a = {0, 0, 0, 0, 0, 0}};
> > >
> > > +  vhost_net_get_config(get_vhost_net(nc->peer), (uint8_t *)&hwcfg, ETH_ALEN);
> > > +
> > > +  /* For VDPA device: Only two situations are acceptable:
> > > +   * 1.The hardware MAC address is the same as the QEMU command line MAC
> > > +   *   address, and both of them are not 0.
> > > +   * 2.The hardware MAC address is NOT 0, and the QEMU command line MAC address
> > > +   *   is 0.
> >
> > Did you mean -device virtio-net-pci,macaddr=0 ? Or you mean mac
> > address is not specified in the qemu command line?
> >
> yes, what I mean is mac address not specified, sorry for the confusion,
> I will rewrite this part
> Thanks
> cindy
>

Thanks


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ