[libvirt] [PATCH] util: allow tap-based guest interfaces to have MAC address prefix 0xFE

[Michal Privoznik]

On 8/11/19 10:59 PM, Laine Stump wrote:
> Back in July 2010, commit 6ea90b84 (meant to resolve
> https://bugzilla.redhat.com/571991 ) added code to set the MAC address
> of any tap device to the associated guest interface's MAC, but with
> the first byte replaced with 0xFE. This was done in order to assure
> that
> 
> 1) the tap MAC and guest interface MAC were different (otherwise L2
>     forwarding through the tap would not work, and the kernel would
>     repeatedly issue a warning stating as much).
> 
> 2) any bridge device that had one of these taps attached would *not*
>     take on the MAC of the tap (leading to network instability as
>     guests started and stopped)
> 
> A couple years later, https://bugzilla.redhat.com/798467 was filed,
> complaining that a user could configure a tap-based guest interface to
> have a MAC address that itself had a first byte of 0xFE, silently
> (other than the kernel warning messages) resulting in a non-working
> configuration. This was fixed by commit 5d571045, which logged an
> error and failed the guest start / interface attach if the MAC's first
> byte was 0xFE.
> 
> Although this restriction only reduces the potential pool of MAC
> addresses from 2^46 (last two bits of byte 1 must be set to 10) by
> 2^32 (still 4 orders of magnitude larger than the entire IPv4 address
> space), it also means that management software that autogenerates MAC
> addresses must have special code to avoid an 0xFE prefix. Now after 7
> years, someone has noticed this restriction and requested that we
> remove it.
> 
> So instead of failing when 0xFE is found as the first byte, this patch
> removes the restriction by just replacing the first byte in the tap
> device MAC with 0xFA if the first byte in the guest interface is
> 0xFE. 0xFA is the next-highest value that still has 10 as the lowest
> two bits, and still
> 
> 2) meets the requirement of "tap MAC must be different from guest
>     interface MAC", and
> 
> 3) is high enough that there should never be an issue of the attached
>     bridge device taking on the MAC of the tap.
> 
> The result is that *any* MAC can be chosen by management software
> (although it would still not work correctly if a multicast MAC (lowest
> bit of first byte set to 1) was chosen), but that's a different
> issue).
> 
> Signed-off-by: Laine Stump <laine at redhat.com>
> ---
> 
> Yes, I find it slightly problematic that the same setting is in two
> different places in the code, but 1) that is pre-existing, and 2) if I
> moved the MAC address setting down one level into virNetDevTapCreate(),
> the code would *still* need to be duplicated, since there are two
> different implementations of virNetDevTapCreate().  If anyone is
> bothered by this, then I can resubmit with an extra patch to add a new
> virNetDevTapCreate() that just calls a platform-specific
> virNetDevTapCreateInternal(), then sets the tap mac address. Only by
> request though :-).
> 
>   src/qemu/qemu_interface.c | 11 ++++++++++-
>   src/util/virnetdevtap.c   | 26 ++++++++++++--------------
>   2 files changed, 22 insertions(+), 15 deletions(-)

Reviewed-by: Michal Privoznik <mprivozn at redhat.com>

Michal