qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] OEM Windows in Qemu


From: inbox
Subject: Re: [Qemu-devel] OEM Windows in Qemu
Date: Wed, 21 Dec 2011 21:44:25 -0700
User-agent: Web-Based Email 5.6.09

Michael,

Thanks for the response.  Since you wrote the patch I'm using I'd say
you are the most qualified to answer questions about it. :)


>Note that for winXP, the only thing needed from the bios is to _mention_ -
>anywhere in its memory - name of your manufacturer. That is, you can
>add any table with just a string - say - "ASUS_Notebook" in it, winXP
>does an equivalent of memmem() function on the bios content to find if
>it is supposed to be right OEM.

I'm not an expert on this by any means, but what I've read on the net is
that Windows looks for some special bytes in RAM that correspond to the
OEM manufacturer.  Apparently this is set in the OEMBIOS.DAT or .CAT
file on the installation cd rom along with the location in memory where
it looks for the data.  This is an example listing which I've read
specifies the RAM addresses, offset, and bytes to look for.

DELL (OEMBIOS.CAT CRC32=B6F0EEFD)

f000,e076,0010,Dell System
f000,e840,0010,Dell Computer
f000,49a9,0010,Dell System
f000,e05e,0010,Dell System
f000,e838,0018,Dell Inc


>WinXP requires "SLIC version 1.0", which is reduced to just having a string
>with the name of your OEM in the bios (one possible place is the SLIC table).
>More recent version of SLIC (2.1 I think) is needed to activate windows7.

This is the part that is confusing me.  I've read that SLIC 2.0 is
backward compatible with SLIC 1.0 so XP should activate just fine with a
working SLIC 2.0.  And your patch does apparently produce a signed SLIC
2.0 
But my OEM copy of XP complains about the BIOS produced with your patch.
 I can only guess there is some critical piece missing that Windows 7
doesn't care about.


>While I'm the author of the howto you mentioned, so my "opinion" here is
>biased, but still I can say that several other people used this way to
>run oem versions of windows7 and windowsVista in their VMs, and sent me
>their thanks. I also found this way mentioned in vmware-related forums.

You can add my name to the list of people offers thanks for that patch. 
:) I'm sure I'll want to install Windows 7 at some point also.


>I've no idea what does these tools do. For testing I just boot linux
>and check if it can see the tables with the content I've used (somewhere
>in /sys/firmware/acpi/tables). For further testing I boot my OEM-preinstalled
>copy of windows to verify it still thinks it is OEM-activated. I also
>tried to actually activate win7 in a VM, using slic+certificate from
>a "random" OEM (these are available on the 'net despite being M$ high-secret),
>and it worked just fine too.

I haven't yet installed a linux VM to check the acpi/tables but here is
what is on the host:
/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20100528
 *
 * Disassembly of slic.dat, Mon Dec 19 22:31:44 2011
 *
 * ACPI Data Table [SLIC]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h 0000  4]                    Signature : "SLIC"    /* Software
Licensing Description Table */
[004h 0004  4]                 Table Length : 00000176
[008h 0008  1]                     Revision : 01
[009h 0009  1]                     Checksum : 5F
[00Ah 0010  6]                       Oem ID : "DELL  "
[010h 0016  8]                 Oem Table ID : "M07    "
[018h 0024  4]                 Oem Revision : 27D80202
[01Ch 0028  4]              Asl Compiler ID : "ASL "
[020h 0032  4]        Asl Compiler Revision : 00000061

These are the results of a dmidecode -t0

SMBIOS 2.4 present.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: Dell Inc.
        Version: A06
        Release Date: 02/02/2008
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 576 kB

I'm guessing this may be significant because the DMI data is different
in the VM.  Looking at a memory dump of the VM ACPI tables I see several
tables: RSDP, RSDT, FACP, SSDT, APIC, HPET, SLIC, FACS, and DSDT.
RSDT and SLIC shows what we would expect: "OEM ID= DELL" "OEM Table ID =
M07" "OEM Revision = 27D80202".  In other words all the exported SLIC
data.  But the other tables show "OEM ID = BOCHS" "OEM Table ID = BXPC"
"OEM Revision = 00000001"  Maybe Windows XP reads from the "wrong"
tables?

I assume Seabios reads all of that from src/config.h is that right?  I
could just change that data and recompile, but would I need to change
anything else also?  Would that create maybe some other problems down
the road?

>Besides all this, you obviously should have the right OEM version of
>windows, wich "knows" this very OEM you're pretending to be (if you're
>installing new VM and not using a pre-installed copy). For win7 this
>means valid certificate belonging to this OEM is installed in the system.

Right.  It bears mentioning that the OEM cd I have activates properly
when installed directly on the host.

>I wont provide any further details about it, because someone thinks it
>is hackish and "blackish" territory.

You can mail me offlist for that if you like. :)

Brian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]