You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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.
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:
VM:
Additional context
Possible cause: https://bugs.launchpad.net/qemu/+bug/1119281/comments/9
The text was updated successfully, but these errors were encountered: