VirtIO network apdapter cause UuidCreateSequential() generate GUID without adapter's MAC Address

[izeroo]

Describe the bug VirtIO network apdapter cause UuidCreateSequential() generate GUID without adapter's MAC Address

To Reproduce Download and run the attachment in the following bug report(or you can compile your own with the source) https://bugs.launchpad.net/qemu/+bug/1119281?comments=all

Run the executable. Record the result. Whose last 48 bits is inconsistent with VirtoIO network adapter's mac.

Reboot. The GUID may change. Still not consistent with VirtoIO network adapter's mac.

Expected behavior GUID should contain the MAC address of our network adapter. Refer: "For security reasons, UuidCreate was modified so that it no longer uses a machine's MAC address to generate UUIDs. UuidCreateSequential was introduced to allow creation of UUIDs using the MAC address of a machine's Ethernet card." https://learn.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidcreatesequential

Screenshots N/A.

Host:

• Distro: Ubuntu 22 LTS
• Kernel version: 6.2.0-39-generic
• QEMU: QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.15)
• QEMU command line : N/A
• libvirt version: libvirtd (libvirt) 8.0.0
• libvirt XML file

  <interface type="network">
  <mac address="52:54:00:xx:xx:xx"/>
  <source network="network"/>
  <model type="virtio"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
  </interface>

VM:

• Windows version: LTSC 2019
• Which driver has a problem: virtionet
• Driver version or commit hash that was used to build the driver: 100.93.104.24000

Additional context Possible cause: https://bugs.launchpad.net/qemu/+bug/1119281/comments/9

[YanVugenfirer]

Thank you for reporting

Out of academic curiosity, what's the reason to use insecure function to begin with?

Another question, what happens with e1000 adapter in QEMU?

Thanks.

[izeroo]

Thank you for reporting

Out of academic curiosity, what's the reason to use insecure function to begin with?

Another question, what happens with e1000 adapter in QEMU?

Thanks.

Thank you for getting back to me so quickly.

The reason is that I'm using a software which uses the GUID from UuidCreateSequential() to obtain mac address to bind to a specific macine.

Changing to e1000 with the same mac will return the GUID with MAC address in the ending.

I come across the code snippet in ParaNdis_Oid.cpp, which proves my guess.

    case OID_GEN_VENDOR_ID:
        SETINFO(ul, 0x00ffffff);
        break;

And I looked up IEEE OUI list just now. There is no entry for RedHat or this OUI: 52:54:00(QEMU?). Though it's a valid non-multicast MAC, Windows still will not use it since the VENDOR_ID is virtual. So I think it is actually expected behaviour but a little bit confusing since intel and vmware all have their OUI number. So this only occurs to virtio driver with QEMU.

[YanVugenfirer]

Red Hat doesn't have a registered IEEE vendor ID.

In any case, a system can have multiple NICs, isn't it better to use https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersinfo or device enumeration to get MAC addresses?

[izeroo]

@YanVugenfirer Sure it is.

It's interesting that I asked ChatGPT, and it responded the same method. Maybe that software is just sponsored by ChatGPT lol.

Closing the issue now since it's but a bug.

The conversation:

Me

Obtain MAC address in Python?

ChatGPT

Sure thing! You can obtain the MAC address of a system in Python using the getnode() function from the uuid module. Here's a simple example:

import uuid

def get_mac_address():
    mac = ':'.join(['{:02x}'.format((uuid.getnode() >> elements) & 0xff) for elements in range(2,7)][::-1])
    return mac

mac_address = get_mac_address()
print("MAC Address:", mac_address)