The virtio network device breaks UuidCreateSequential()

Bug #1119281 reported by Francois Gouget on 2013-02-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Undecided
Unassigned

Bug Description

UuidCreateSequential() usually creates version 1 UUIDs (1) which means they contain the main network card's MAC address. However when using a virtio network card and driver the UUIDs contain random data instead of the guest's MAC address. Changing the network card to either the default rtl8139 one or the e1000 one fixes the issue.

Here is the software I have tested this with:
 * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively)
 * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
 * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.

Here is how to test for this issue:
* Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver.

* Boot the guest and copy the uuidtest.exe file (see attachement) to it

* On the command line, type 'ipconfig /all'. Give you the correct network card's MAC address on a line like the one below:

        Physical Address. . . . . . . . . : 52-54-00-C7-0E-97

* Run uuidtest.exe. It will show the VM returning a UUID with the wrong MAC address, and quite possibly even a multicast MAC address! (3). In the example below 'f75292c62787' should have been the MAC address. Note that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it returns 0.

        UuidCreateSequential() returned 0
        uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
        Got a version 1 UUID
        The UUID does not contain a non-multicast MAC address

* Reboot and notice uuidtest.exe now reports a different value where the MAC address should be.

* Shut down the VM and switch the network card to rtl8139, install the drivers, run uuidtest.exe and notice that the last group of digits finally contains the correct MAC address.

(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
(2) Best do it with a single card to avoid confusion over which is the primary one.
(3) If the first byte of the address is odd then this is a multicast address.
    https://en.wikipedia.org/wiki/MAC_address#Address_details

Francois Gouget (fgouget) wrote :

On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote:
> Public bug reported:
>
> UuidCreateSequential() usually creates version 1 UUIDs (1) which means
> they contain the main network card's MAC address. However when using a
> virtio network card and driver the UUIDs contain random data instead of
> the guest's MAC address. Changing the network card to either the default
> rtl8139 one or the e1000 one fixes the issue.

CCing Yan and Vadim, who work on the virtio-win drivers.

>
> Here is the software I have tested this with:
> * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and Experimental respectively)
> * The 0.1-49 and 0.1-52 Windows virtio drivers from https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
> * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
>
>
> Here is how to test for this issue:
> * Set up a Windows guest with a single network card(2), a virtio one and install the corresponding driver.
>
> * Boot the guest and copy the uuidtest.exe file (see attachement) to it
>
> * On the command line, type 'ipconfig /all'. Give you the correct
> network card's MAC address on a line like the one below:
>
> Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
>
> * Run uuidtest.exe. It will show the VM returning a UUID with the wrong
> MAC address, and quite possibly even a multicast MAC address! (3). In
> the example below 'f75292c62787' should have been the MAC address. Note
> that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY
> for virtio cards but that on Windows 7 it returns 0.
>
> UuidCreateSequential() returned 0
> uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
> Got a version 1 UUID
> The UUID does not contain a non-multicast MAC address
>
> * Reboot and notice uuidtest.exe now reports a different value where the
> MAC address should be.
>
> * Shut down the VM and switch the network card to rtl8139, install the
> drivers, run uuidtest.exe and notice that the last group of digits
> finally contains the correct MAC address.
>
>
> (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
> (2) Best do it with a single card to avoid confusion over which is the primary one.
> (3) If the first byte of the address is odd then this is a multicast address.
> https://en.wikipedia.org/wiki/MAC_address#Address_details
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
>
> ** Attachment added: "Test executable and source"
> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2

Download full text (4.1 KiB)

On Mon, Feb 11, 2013 at 11:13 AM, Stefan Hajnoczi <email address hidden>wrote:

> On Fri, Feb 08, 2013 at 10:45:03AM -0000, Francois Gouget wrote:
> > Public bug reported:
> >
> > UuidCreateSequential() usually creates version 1 UUIDs (1) which means
> > they contain the main network card's MAC address. However when using a
> > virtio network card and driver the UUIDs contain random data instead of
> > the guest's MAC address. Changing the network card to either the default
> > rtl8139 one or the e1000 one fixes the issue.
>
> CCing Yan and Vadim, who work on the virtio-win drivers.
>
> >
> > Here is the software I have tested this with:
> > * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
> Experimental respectively)
> > * The 0.1-49 and 0.1-52 Windows virtio drivers from
> https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
> > * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
> >
> >
> > Here is how to test for this issue:
> > * Set up a Windows guest with a single network card(2), a virtio one and
> install the corresponding driver.
> >
> > * Boot the guest and copy the uuidtest.exe file (see attachement) to it
> >
> > * On the command line, type 'ipconfig /all'. Give you the correct
> > network card's MAC address on a line like the one below:
> >
> > Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
> >
> > * Run uuidtest.exe. It will show the VM returning a UUID with the wrong
> > MAC address, and quite possibly even a multicast MAC address! (3). In
> > the example below 'f75292c62787' should have been the MAC address. Note
> > that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY
> > for virtio cards but that on Windows 7 it returns 0.
> >
> > UuidCreateSequential() returned 0
> > uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
> > Got a version 1 UUID
> > The UUID does not contain a non-multicast MAC address
> >
> > * Reboot and notice uuidtest.exe now reports a different value where the
> > MAC address should be.
> >
> > * Shut down the VM and switch the network card to rtl8139, install the
> > drivers, run uuidtest.exe and notice that the last group of digits
> > finally contains the correct MAC address.
> >
> >
> > (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
> > (2) Best do it with a single card to avoid confusion over which is the
> primary one.
> > (3) If the first byte of the address is odd then this is a multicast
> address.
> > https://en.wikipedia.org/wiki/MAC_address#Address_details
> >
> > ** Affects: qemu
> > Importance: Undecided
> > Status: New
> >
> > ** Attachment added: "Test executable and source"
> >
> https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2
>

I did a quick check for this issue. First off all
while UuidCreateSequential should use mac address, there is no indication
that it must do it. And as we don't have source code for Rpcrt4.lib it is
hard to estimated what should be the exact behavior of this function (I can
use reactos source code - but we cannot count on it).
What I see from our debug trace that there are no OID call...

Read more...

Francois Gouget (fgouget) wrote :

This bug is still present in QEM 1.6.0 (qemu-system-x86 1.6.0+dfsg-1) and/or Virtio 0.1-65.

Thomas Huth (th-huth) wrote :

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

Changed in qemu:
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for QEMU because there has been no activity for 60 days.]

Changed in qemu:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers