Could ether_gen_addr be updated to take into account the zero'd hostuuid and handle appropriately like you mentioned below?
On Thu, Apr 15, 2021 at 03:12:14PM -0500, Kyle Evans wrote: > I think it'd be the right choice, but it needs a little work first. > e.g., it's not a good fit right now for VMs that don't use loader, for > instance, because it relies on the hostuuid actually being somewhat > unique or else it generates the same MAC address across different VMs > and you end up with conflicts in the broadcast domain. I think there's > a good argument to make for having it check if the hostuuid is the > default all-0 hostuuid and just generating a random address as this > does right now. I might go ahead and prepare such a change and > document the KPI in the process. > > On Thu, Apr 15, 2021 at 3:06 PM Kevin Bowling <kevin.bowl...@kev009.com> > wrote: > > > > I would like to discuss this further, it crossed my mind, but none of > > the intel drivers currently use it. If this is the right KPI I think > > a review should be prepared that updates e1000, ixgbe (ixv), ixl > > (iavf) in one go. > > > > Regards, > > Kevin > > > > On Thu, Apr 15, 2021 at 12:36 PM Kyle Evans <kev...@freebsd.org> wrote: > > > > > > On Thu, Apr 15, 2021 at 2:32 PM Ronald Klop <ronald-li...@klop.ws> wrote: > > > > > > > > On 4/15/21 8:48 PM, Kevin Bowling wrote: > > > > > The branch main has been updated by kbowling (ports committer): > > > > > > > > > > URL: > > > > > https://cgit.FreeBSD.org/src/commit/?id=68a46f11eadab48a1da9e3d3900569a6a1ce142e > > > > > > > > > > commit 68a46f11eadab48a1da9e3d3900569a6a1ce142e > > > > > Author: Kevin Bowling <kbowl...@freebsd.org> > > > > > AuthorDate: 2021-04-15 18:45:02 +0000 > > > > > Commit: Kevin Bowling <kbowl...@freebsd.org> > > > > > CommitDate: 2021-04-15 18:45:02 +0000 > > > > > > > > > > e1000: Restore VF interface random MAC > > > > > > > > > > Restore 525e07418c77 after the iflib conversion of igb(4). This > > > > > reenables random MAC address generation when attaching to a VF > > > > > with a > > > > > zeroed MAC. > > > > > > > > > > PR: 253535 > > > > > Reported by: Balaev PA <m...@void.so> > > > > > Reviewed by: markj > > > > > MFC after: 2 weeks > > > > > Differential Revision: https://reviews.freebsd.org/D29785 > > > > > --- > > > > > sys/dev/e1000/if_em.c | 21 ++++++++++++++++++--- > > > > > 1 file changed, 18 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c > > > > > index 6f022c80c01c..79a617b3342f 100644 > > > > > --- a/sys/dev/e1000/if_em.c > > > > > +++ b/sys/dev/e1000/if_em.c > > > > > @@ -1061,9 +1061,17 @@ em_if_attach_pre(if_ctx_t ctx) > > > > > } > > > > > > > > > > if (!em_is_valid_ether_addr(hw->mac.addr)) { > > > > > - device_printf(dev, "Invalid MAC address\n"); > > > > > - error = EIO; > > > > > - goto err_late; > > > > > + if (adapter->vf_ifp) { > > > > > + u8 addr[ETHER_ADDR_LEN]; > > > > > + arc4rand(&addr, sizeof(addr), 0); > > > > > + addr[0] &= 0xFE; > > > > > + addr[0] |= 0x02; > > > > > + bcopy(addr, hw->mac.addr, sizeof(addr)); > > > > > + } else { > > > > > + device_printf(dev, "Invalid MAC address\n"); > > > > > + error = EIO; > > > > > + goto err_late; > > > > > + } > > > > > > > > > > > > Just curious. Would ether_gen_addr() be useful here? > > > > It is implemented in net/if_ethersubr.c. > > > > > > > > > > I had asked myself the same question, but I suspect these machines may > > > not necessarily have a hostuuid preloaded to avoid collisions from the > > > generated addresses. > > > > > > Thanks, > > > > > > Kyle Evans > _______________________________________________ > dev-commits-src-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all > To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org" -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
