netdev - Re: [net-next 0/8][pull request] 1GbE Intel Wired LAN Driver Updates 2018-01-24

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]

Date:   Wed, 24 Jan 2018 16:10:37 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     jeffrey.t.kirsher@...el.com
Cc:     netdev@...r.kernel.org, nhorman@...hat.com, sassmann@...hat.com,
        jogreene@...hat.com
Subject: Re: [net-next 0/8][pull request] 1GbE Intel Wired LAN Driver
 Updates 2018-01-24

From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Date: Wed, 24 Jan 2018 12:55:12 -0800

> This series contains updates to igb and e1000e only.

Pulled, however:

> Corinna Vinschen implements the ability to set the VF MAC to
> 00:00:00:00:00:00 via RTM_SETLINK on the PF, to prevent receiving
> "invlaid argument" when libvirt attempts to restore the MAC address back
> to its original state of 00:00:00:00:00:00.

This is really a mess and the wrong way to go about this.

No interface, even a VF, should come up or ever have an invalid
MAC addres like all-zeros.  That's the fundamental problem and
once you fix that all of this other crazy logic and workarounds
no longer become necessary.

Whatever it takes, just do it.  We can even come up with a global
MAC address range that on a Linux system is reserved for VFs to
come up with.

Thanks.