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]
Message-ID: <CACLfguXjiyp+Ya4mUKXu6Dmb3Wx5wW0bbNGRSFWE-Z0E5gALTA@mail.gmail.com>
Date: Wed, 28 Aug 2024 17:00:01 +0800
From: Cindy Lu <lulu@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: Dragos Tatulea <dtatulea@...dia.com>, "Michael S. Tsirkin" <mst@...hat.com>, 
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez <eperezma@...hat.com>, 
	si-wei.liu@...cle.com, Jiri Pirko <jiri@...dia.com>, virtualization@...ts.linux.dev, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vdpa/mlx5: Use random MAC address when no nic vport MAC set

On Wed, 28 Aug 2024 at 09:51, Jason Wang <jasowang@...hat.com> wrote:
>
> On Wed, Aug 28, 2024 at 12:03 AM Dragos Tatulea <dtatulea@...dia.com> wrote:
> >
> > When the vdpa device is configured without a specific MAC
> > address, the vport MAC address is used. However, this
> > address can be 0 which prevents the driver from properly
> > configuring the MPFS and breaks steering.
> >
> > The solution is to simply generate a random MAC address
> > when no MAC is set on the nic vport.
> >
> > Now it's possible to create a vdpa device without a
> > MAC address and run qemu with this device without needing
> > to configure an explicit MAC address.
> >
> > Signed-off-by: Dragos Tatulea <dtatulea@...dia.com>
> > Reviewed-by: Jiri Pirko <jiri@...dia.com>
>
> Acked-by: Jason Wang <jasowang@...hat.com>
>
> (Adding Cindy for double checking if it has any side effect on Qemu side)
>
> Thanks
>
But Now there is a bug in QEMU: if the hardware MAC address does not
match the one in the QEMU command line, it will cause traffic loss.

So, Just an FYI here: if your patch merged, it may cause traffic loss.
and now I'm working in the fix it in qemu, the link is
https://patchew.org/QEMU/20240716011349.821777-1-lulu@redhat.com/
The idea of this fix is
There are will only two acceptable situations for qemu:
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.

Thanks
Cindy


> > ---
> >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index fa78e8288ebb..1c26139d02fe 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3824,6 +3824,9 @@ static int mlx5_vdpa_dev_add(struct vdpa_mgmt_dev *v_mdev, const char *name,
> >                 err = mlx5_query_nic_vport_mac_address(mdev, 0, 0, config->mac);
> >                 if (err)
> >                         goto err_alloc;
> > +
> > +               if (is_zero_ether_addr(config->mac))
> > +                       eth_random_addr(config->mac);
> >         }
> >
> >         if (!is_zero_ether_addr(config->mac)) {
> > --
> > 2.45.1
> >
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ