[Bug 10264] Games fail to start with "you must be administrator" message (Tages copy protection)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10264


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #33 from Anastasius Focht <focht at gmx.net>  2009-06-19 06:04:06 ---
Hello,

it will be a long way until TAGES drivers really begin to talk. This requires a
considerable amount of additional infrastructure and rethought of current
design.
Many ntoskrnl API are just stubs - doing nothing.

One of the main problems is that Wine has to emulate the concept of "kernel"
address space vs. user address space mappings somehow (out-of-process context).

This specific failure is due to IoAllocateMdl() being a stub:

--- snip ---
0009:Call KERNEL32.CreateFileW(0032c61c
L"\\\\.\\lirsgt",c0000000,00000000,00000000,00000003,40000000,00000000)
ret=0040108f
0009:Ret  KERNEL32.CreateFileW() retval=00000038 ret=0040108f
0009:Call
KERNEL32.DeviceIoControl(00000038,0022e013,0032c840,00000000,0032c840,00000000,0032c858,00000000)
ret=00401c9a
...
001a:trace:ntoskrnl:process_ioctl ioctl 22e013 device 0x11d740 in_size 0
out_size 0
...
001a:Call driver dispatch 0x652140 (device=0x11d740,irp=0x64e750)
001a:Call
ntoskrnl.exe.IoAllocateMdl(0011dd20,00000005,00000000,00000000,00000000)
ret=006516bd
001a:fixme:ntoskrnl:IoAllocateMdl stub: 0x11dd20, 5, 0, 0, (nil)
001a:Ret  ntoskrnl.exe.IoAllocateMdl() retval=00000000 ret=006516bd
001a:trace:ntoskrnl:__regs_IofCompleteRequest 0x64e750 0
...
001a:Ret  driver dispatch 0x652140 (device=0x11d740,irp=0x64e750)
retval=c000009a
...
0009:Ret  KERNEL32.DeviceIoControl() retval=00000000 ret=00401c9a 
--- snip ---

The kernel driver receives a "usermode" pointer within a struct as
input to DeviceIoControl. To access the data from user pointer location, the
kernel driver has to map it into "kernel" space context.

It wouldn't be necessary to build a MDL if the kernel driver is the top level
driver invoked from the calling process context (via DeviceIoControl) which can
be read/written to directly -> ProbeForRead/Write, so I assume they went safe
way considering out-of-process context.

Within driver dispatch handler it basically does:

mdl = IoAllocateMdl(userBuf, userBufLen, FALSE, FALSE, NULL);
...
MmProbeAndLockPages(mdl, UserMode, IoWriteAccess);
...

See:

http://msdn.microsoft.com/en-us/library/aa490866.aspx (IoAllocateMdl)
http://msdn.microsoft.com/en-us/library/aa489506.aspx (Using MDLs)

If you return an MDL, you also need a MmProbeAndLockPages() stub because the
driver tries to lock the virtual to physical mapping of the buffer.
After that you need MmMapLockedPagesSpecifyCache() because the driver wants the
user virtual address for the MDL...

To be honest: I wouldn't start with that stuff until there is proper
infrastructure and concept in Wine, supporting such address space manipulations
(e.g. "fake" user space vm address space mappings using special buffers which
trigger proper process memory reads/writes for the target process when being
accessed from kernel driver).

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.