* [Qemu-devel] OEM Windows in Qemu
@ 2011-12-20 7:09 inbox
2011-12-20 9:49 ` Stefan Hajnoczi
0 siblings, 1 reply; 10+ messages in thread
From: inbox @ 2011-12-20 7:09 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/html, Size: 1585 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
2011-12-20 7:09 [Qemu-devel] OEM Windows in Qemu inbox
@ 2011-12-20 9:49 ` Stefan Hajnoczi
0 siblings, 0 replies; 10+ messages in thread
From: Stefan Hajnoczi @ 2011-12-20 9:49 UTC (permalink / raw)
To: inbox; +Cc: qemu-devel
On Tue, Dec 20, 2011 at 12:09:41AM -0700, inbox@expertcomputerrepair.com wrote:
> <html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>I've been trying for several days now to get my OEM copy of Windows XP to pre-activate properly in Qemu-kvm. I saw the instructions for patching the seabios here:</div><div><a href="http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html">http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html</a><br></div><div><br></div><div>That seems to have worked as expected. When I boot, it shows the newly compiled BIOS, but Windows fails to detect the SLIC codes which I copied from my working Dell system as per the instructions. My research so far has turned up the existence of multiple versions of SLP/SLIC which I think may account for this.</div><div><br></div><div>Can anyone confirm what version of SLP the patch posted to this list is effective at emulating? Is there an easy way to modify the patch to support a different version of SLP?</div><div><br></div><div>I've installed several low level BIOS scanning tools in the VM to troubleshoot and gather information. None of the tools I've used (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM. But another tool (ReadWrite) shows a valid Dell SLP 2.0 signature. This leads me to believe that either I didn't copy the right SLIC information from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0.</div><div><br></div><div>Any advice or help would be appreciated.</div><div><br></div><div>Brian<br></div><div><br></div><div><br></div></span></body></html>
Please send plain text emails, not HTML to the qemu-devel mailing list.
Your email client or webmail should have an option to choose between
text-only, HTML-only, and text-and-HTML. Either text-only or
text-and-HTML is fine.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
@ 2011-12-24 6:09 inbox
0 siblings, 0 replies; 10+ messages in thread
From: inbox @ 2011-12-24 6:09 UTC (permalink / raw)
To: qemu-devel
Jernej Simon?i? <jernej@ena.si> wrote:
>That's the exact reason - the strings have to be present in the
>correct memory region. You can use SLICToolkit (in SLP1.0 tab) to
>verify if the strings are present at the right address.
Alright then, do you know how to modify those values in qemu?
Brian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
2011-12-23 6:11 inbox
2011-12-23 6:21 ` ronnie sahlberg
@ 2011-12-23 8:43 ` Jernej Simončič
1 sibling, 0 replies; 10+ messages in thread
From: Jernej Simončič @ 2011-12-23 8:43 UTC (permalink / raw)
To: inbox@expertcomputerrepair.com on [qemu-devel]
On Friday, December 23, 2011, 7:11:08, inbox@expertcomputerrepair.com wrote:
> I think the key is those specific
> memory addresses I mentioned earlier.
That's the exact reason - the strings have to be present in the
correct memory region. You can use SLICToolkit (in SLP1.0 tab) to
verify if the strings are present at the right address.
--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >
Nature will tell you a direct lie if she can.
-- Darwin's Observation
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
2011-12-23 6:11 inbox
@ 2011-12-23 6:21 ` ronnie sahlberg
2011-12-23 8:43 ` Jernej Simončič
1 sibling, 0 replies; 10+ messages in thread
From: ronnie sahlberg @ 2011-12-23 6:21 UTC (permalink / raw)
To: inbox; +Cc: Michael Tokarev, qemu-devel
Why not just buy a non-OEM version ?
They are surely not tied to a specific piece of hardware and its
licence should allow to run on "arbitrary PC HW you happen to want to
install/run it on once activated"
On Fri, Dec 23, 2011 at 5:11 PM, <inbox@expertcomputerrepair.com> wrote:
>
>
>>"My patch" does not produce any SLIC at all. The instructions mentions
>>using SLIC from your machine - "my patch" is just a way to _embed_ a given
>>data into VM, not a way to "produce" anything. You get in your VM what
>>you have outside, either in a file or in your own BIOS, depending on where
>>you took that data from.
>
> Right, I meant to say simply that it did copy the SLIC in a recognizable
> form and embed it into the BIOS.
>
>
>
>>Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies,
>>all other tables does not matter for win7. And yes, it might be different
>>for winXP - you may try setting all tables in VM to be of DELL OEM and see
>>what happens.
>
> I had high hopes for this, but no joy. All the DMI tables now read Dell
> Inc but XP refuses to activate. I think the key is those specific
> memory addresses I mentioned earlier. I tried raw write of "Dell Inc"
> into the specified address space, but there are 2 problems with this.
> First is that the address space already contains data so I overwrote
> something. Second even then Windows did not activate, I think the
> activation check only occurs at certain times, probably on boot, so I
> made my changes after it checked and it didn't check again and so didn't
> see the changes I made.
>
> I need to modify the BIOS to contain the string so it is visible on boot
> without me having to manually edit it. Is there a way to hardcode the
> string into a specific memory address when I compile the BIOS?
>
> Brian
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
@ 2011-12-23 6:11 inbox
2011-12-23 6:21 ` ronnie sahlberg
2011-12-23 8:43 ` Jernej Simončič
0 siblings, 2 replies; 10+ messages in thread
From: inbox @ 2011-12-23 6:11 UTC (permalink / raw)
To: Michael Tokarev; +Cc: qemu-devel
>"My patch" does not produce any SLIC at all. The instructions mentions
>using SLIC from your machine - "my patch" is just a way to _embed_ a given
>data into VM, not a way to "produce" anything. You get in your VM what
>you have outside, either in a file or in your own BIOS, depending on where
>you took that data from.
Right, I meant to say simply that it did copy the SLIC in a recognizable
form and embed it into the BIOS.
>Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies,
>all other tables does not matter for win7. And yes, it might be different
>for winXP - you may try setting all tables in VM to be of DELL OEM and see
>what happens.
I had high hopes for this, but no joy. All the DMI tables now read Dell
Inc but XP refuses to activate. I think the key is those specific
memory addresses I mentioned earlier. I tried raw write of "Dell Inc"
into the specified address space, but there are 2 problems with this.
First is that the address space already contains data so I overwrote
something. Second even then Windows did not activate, I think the
activation check only occurs at certain times, probably on boot, so I
made my changes after it checked and it didn't check again and so didn't
see the changes I made.
I need to modify the BIOS to contain the string so it is visible on boot
without me having to manually edit it. Is there a way to hardcode the
string into a specific memory address when I compile the BIOS?
Brian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
2011-12-22 4:44 inbox
@ 2011-12-22 6:36 ` Michael Tokarev
0 siblings, 0 replies; 10+ messages in thread
From: Michael Tokarev @ 2011-12-22 6:36 UTC (permalink / raw)
To: inbox; +Cc: qemu-devel
On 22.12.2011 08:44, inbox@expertcomputerrepair.com wrote:
[]
>> 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
"My patch" does not produce any SLIC at all. The instructions mentions
using SLIC from your machine - "my patch" is just a way to _embed_ a given
data into VM, not a way to "produce" anything. You get in your VM what
you have outside, either in a file or in your own BIOS, depending on where
you took that data from.
> 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.
Well. It should be both - win7 in my case cared about alot more details
than winXP. But I must admit that I never actually installed oem version
of winXP, -- I used an installed version to verify what it needs, and
found that I can just mention the right string in the BIOS. Maybe it
is not sufficient for actual "activation" procedure, I dunno.
[]
> 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?
Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies,
all other tables does not matter for win7. And yes, it might be different
for winXP - you may try setting all tables in VM to be of DELL OEM and see
what happens.
> 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?
neither seabios nor qemu/kvm actually use these OEM strings, so there
should be no problems.
/mjt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
@ 2011-12-22 4:44 inbox
2011-12-22 6:36 ` Michael Tokarev
0 siblings, 1 reply; 10+ messages in thread
From: inbox @ 2011-12-22 4:44 UTC (permalink / raw)
To: Michael Tokarev; +Cc: Stefan Hajnoczi, qemu-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
2011-12-20 18:23 inbox
@ 2011-12-21 7:53 ` Michael Tokarev
0 siblings, 0 replies; 10+ messages in thread
From: Michael Tokarev @ 2011-12-21 7:53 UTC (permalink / raw)
To: inbox; +Cc: Stefan Hajnoczi, qemu-devel
On 20.12.2011 22:23, inbox@expertcomputerrepair.com wrote:
> Sorry, I don't normally use this email and didn't realize it was set to
> html.
>
> I've been trying for several days now to get my OEM copy of Windows XP
> to pre-activate properly in Qemu-kvm. I saw the instructions for
> patching the seabios here:
> http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html
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.
> That seems to have worked as expected. When I boot, it shows the newly
> compiled BIOS, but Windows fails to detect the SLIC codes which I copied
> from my working Dell system as per the instructions. My research so far
> has turned up the existence of multiple versions of SLP/SLIC which I
> think may account for this.
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.
> Can anyone confirm what version of SLP the patch posted to this list is
> effective at emulating? Is there an easy way to modify the patch to
> support a different version of SLP?
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.
> I've installed several low level BIOS scanning tools in the VM to
> troubleshoot and gather information. None of the tools I've used
> (OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM. But
> another tool (ReadWrite) shows a valid Dell SLP 2.0 signature. This
> leads me to believe that either I didn't copy the right SLIC information
> from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0.
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.
This is about win7, not winXP, for which I used real bios modification
way in the past to just put a single string into BIOS of my machine for
it to recognize the "OEM-ness".
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.
I wont provide any further details about it, because someone thinks it
is hackish and "blackish" territory.
Thanks,
/mjt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Qemu-devel] OEM Windows in Qemu
@ 2011-12-20 18:23 inbox
2011-12-21 7:53 ` Michael Tokarev
0 siblings, 1 reply; 10+ messages in thread
From: inbox @ 2011-12-20 18:23 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel
Sorry, I don't normally use this email and didn't realize it was set to
html.
I've been trying for several days now to get my OEM copy of Windows XP
to pre-activate properly in Qemu-kvm. I saw the instructions for
patching the seabios here:
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg03080.html
That seems to have worked as expected. When I boot, it shows the newly
compiled BIOS, but Windows fails to detect the SLIC codes which I copied
from my working Dell system as per the instructions. My research so far
has turned up the existence of multiple versions of SLP/SLIC which I
think may account for this.
Can anyone confirm what version of SLP the patch posted to this list is
effective at emulating? Is there an easy way to modify the patch to
support a different version of SLP?
I've installed several low level BIOS scanning tools in the VM to
troubleshoot and gather information. None of the tools I've used
(OEMSCAN, Oembios) show a valid SLP 1.0 OEM data in the BIOS/RAM. But
another tool (ReadWrite) shows a valid Dell SLP 2.0 signature. This
leads me to believe that either I didn't copy the right SLIC information
from my Dell PC or the patch is set up to create SLP 2.0 and not 1.0.
Any advice or help would be appreciated.
Brian
_______________________________________________________________________________
Please send plain text emails, not HTML to the qemu-devel mailing list.
Your email client or webmail should have an option to choose between
text-only, HTML-only, and text-and-HTML. Either text-only or
text-and-HTML is fine.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-12-24 6:09 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-20 7:09 [Qemu-devel] OEM Windows in Qemu inbox
2011-12-20 9:49 ` Stefan Hajnoczi
2011-12-20 18:23 inbox
2011-12-21 7:53 ` Michael Tokarev
2011-12-22 4:44 inbox
2011-12-22 6:36 ` Michael Tokarev
2011-12-23 6:11 inbox
2011-12-23 6:21 ` ronnie sahlberg
2011-12-23 8:43 ` Jernej Simončič
2011-12-24 6:09 inbox
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.