Hi,
I want to tackle the problem of loading and accessing kernel drivers again.
Since the previous tries were met with design concerns, lets try to clarify design issues first.
- Services are handled and registered by ADVAPI32.
Currently we handle process type services correctly, which are started using CreateProcess(). These are marked with SERVICE_WIN32 or similar flags.
- Kernel drivers use SERVICE_DRIVER (or SERVICE_KERNEL_DRIVER specifically).
Q: How should those be loaded and where?
Alexandre seems to suggest we start a seperate services.exe and load them in there?
Is this the way to go?
Q: How to start them? CreateProcess(services.exe name.sys) on commandline?
Or via some kind of other control mechanism?
- Filehandles ...
The whole issue of handling the HANDLEs that are necessary is unclear to me.
Ciao, Marcus
* On Wed, 11 Oct 2006, Marcus Meissner wrote:
Services are handled and registered by ADVAPI32.
Currently we handle process type services correctly, which are started using CreateProcess(). These are marked with SERVICE_WIN32 or similar flags.
Right, probably this type is handled correctly, but I guess whether SERVICE_KERNEL_DRIVER type cannot be handled in similar way? I've winedumped *.sys files of some drivers (GIVEIO.SYS was primary target) and saw their dump doesn't contain DLL keyword while EXECUTABLE_IMAGE is still present here.
- Kernel drivers use SERVICE_DRIVER (or SERVICE_KERNEL_DRIVER specifically). Q: How should those be loaded and where? Alexandre seems to suggest we start a seperate services.exe and load them in there? Is this the way to go?
Why not? Very similar is a conclusion that Vitaliy Margolen has wrote up to wine-devel during a discussion [1]. Only difference is that in patch [2] from him Ntoskrnl.exe is started instead of Services.exe.
Q: How to start them? CreateProcess(services.exe name.sys) on commandline? Or via some kind of other control mechanism?
Sounds like an elegant solution to me. But probably some IPC operations will be needed for every non-first instance of Services.exe.
In the patch [2] seems some pipe reading/writing is used for that inside NtLoadDriver()/driver_managment() after the Ntoskrnl.exe was started via NTOSKRNL_connect() <- NtLoadDriver() <- StartServiceW() chain.
I may sound a bit arogant here, but I cannot imagine some very different mechanisms right now :p
- Filehandles ... The whole issue of handling the HANDLEs that are necessary is unclear to me.
Marcus, are you talking about an I/O Alexandre has mentioned in the same thread [3] or about typed handles mentioned in the Mike-vs-Damjan discussion [4] ?
Also I'm sorry to not sit on irc and to don't know latest news on this topic.
[1] http://www.winehq.com/pipermail/wine-devel/2005-September/039862.html [2] http://www.winehq.com/pipermail/wine-devel/2006-January/044250.html [3] http://www.winehq.com/pipermail/wine-devel/2005-September/039910.html [4] http://www.winehq.com/pipermail/wine-devel/2005-September/039905.html
Marcus Meissner wrote:
Hi,
I want to tackle the problem of loading and accessing kernel drivers again.
Since the previous tries were met with design concerns, lets try to clarify design issues first.
I would say there are 4 issues: 1. We need ntoskrnl.exe - it is more of the DLL that all drivers import functions from. As simple as that. There is also hal.dll but most drivers that import it, most likely won't work on Wine. 2. We need a separate process to run this drivers in. It really needs to be a separate process because lots and lots of things are different in user space and kernel space. 3. Need a way to start this new process and tell it to load a driver. 4. Communication between user process and our "fake" kernel.
Services are handled and registered by ADVAPI32.
Currently we handle process type services correctly, which are started using CreateProcess(). These are marked with SERVICE_WIN32 or similar flags.
Kernel drivers use SERVICE_DRIVER (or SERVICE_KERNEL_DRIVER specifically).
Well it's just a hack IMHO that drivers are the same as services. They are really treated differently on windows and they run in different environments.
Q: How should those be loaded and where?
Alexandre seems to suggest we start a seperate services.exe and load them in there? Is this the way to go?
Doesn't really matter. It have to be separate process and it we still have to have ntoskrnl.exe. It seemed more straight forward to me and Ivan to combine both. I'm personally against any artificial "services.exe" that has nothing to do with drivers, but more with services. However it's really up to the men to say what goes. Too bad he never said why.
Q: How to start them? CreateProcess(services.exe name.sys) on commandline?
Or via some kind of other control mechanism?
No you can't use CreateProcess. Kernel drivers have nothing to do with other programs and require totally different startup mechanism. They more of the dlls then real process. In my patch you can see how much stuff is actually bypassed for kernel driver and that it's loaded as a dll and not a process.
Filehandles ...
The whole issue of handling the HANDLEs that are necessary is unclear to me.
File handles are done and don't require anything special. It's already in place. What is required is a "device" object. That's the only way how driver can "expose" itself to a user program. Again see my patch, it has all the relevant pieces that I sent numerous times to wine-patches.
I think unless Alexandre himself explain why none of this work was applied, it's pointless wasting any more time on this. It's just another project that will play dead for few more years until it will be totally useless.
The only parts of the conversation that I recall was about being able to use whatever we come up with for "Wine drivers". I'm not entirely sure what is meant here. And I don't see why can we compile "Wine driver" the same way ntoskrl.exe was compiled - which makes it loadable as-is into what I wrote. It will still have to go through all the required stuff for the real kernel driver.
Also Alexandre mentioned something about being able to use win32api instead of native. Well I'm not sure if this is good idea or not, but again I don't see any problems with that. Of course it have to fit properly into kernel infrastructure.
Of course we can make ntoskrnrl.exe a loadable dll and make it part of user process. However this doesn't look right to me and I'm sure we will hit some problem(s) that will require rewrite of it as a separate process.
Vitaliy Margolen.
(I may perfectly be ignored by some recipients, but well..)
* On Thu, 12 Oct 2006, Vitaliy Margolen wrote:
- Marcus Meissner wrote:
Q: How should those be loaded and where?
Alexandre seems to suggest we start a seperate services.exe and load them in there? Is this the way to go?Doesn't really matter. It have to be separate process and it we still have to have ntoskrnl.exe. It seemed more straight forward to me and Ivan to combine both.
Yes, but...
I'm personally against any artificial "services.exe" that has nothing to do with drivers, but more with services. However it's really up to the men to say what goes. Too bad he never said why.
"services.exe" name isn't very artificial. It comes from real windows. Of course, ProcessExplorer shows driver modules loaded by the g-g-grandparent of "services.exe", by process "System" with PID=4, but using "services.exe" would be closer to NT platforms.
Q: How to start them? CreateProcess(services.exe name.sys) on commandline?
Or via some kind of other control mechanism?No you can't use CreateProcess.
I think Marcus meant "name.sys" as an argv[1] where "services.exe" is for argv[0]. Command line could be just some external way to give notification to main instance of separate process about driver loading.
Kernel drivers have nothing to do with other programs and require totally different startup mechanism. They more of the dlls then real process. In my patch you can see how much stuff is actually bypassed for kernel driver and that it's loaded as a dll and not a process.
Yes, and I would like to share some observations of a noob with list.
Today I have tried to compile ntoskrnl.exe, then checked out master branch, compiled stock Wine, then tried to run win32 app which do simple port I/O after it loads (GIVE)IO.SYS driver. Driver simply loaded, did its initialization and immediatelly exited.
I think unless Alexandre himself explain why none of this work was applied, it's pointless wasting any more time on this.
That patch is still quite large. Maybe you (or someone else) should select some part of it for Alexandre to review?
BTW, I'd like to be able to get some kernel mode/WDM driver for Win32 compiled on disk and to test loading it inside WRT suite. Wouldn't be that nice? The driver could do a pc-speaker beep by perfoming some port I/O, no?
Now I am thinking about Win32 port I/O mapping to I/O under linux. Port I/O is used in some applications and they try to modify IOBitMap in a TSS. It shouldn't be too hard to map such ntoskrnl-call to ioperm()/iopl(), right?
Of course we can make ntoskrnrl.exe a loadable dll and make it part of user process. However this doesn't look right to me
And this doesn't look wrong either (from a WinNT POV).
and I'm sure we will hit some problem(s) that will require rewrite of it as a separate process.
Of course.
Saulius Krasuckas wrote:
Today I have tried to compile ntoskrnl.exe, then checked out master branch, compiled stock Wine, then tried to run win32 app which do simple port I/O after it loads (GIVE)IO.SYS driver. Driver simply loaded, did its initialization and immediatelly exited.
It's enough to read this to see that you have no idea about how windows kernel works. Please download DDK and read through examples.
Oh and forget about process explorer - it's useless for drivers. You should be using devicetree like utility from DDK to see drivers and devices.
Vitaliy
* On Fri, 13 Oct 2006, Vitaliy Margolen wrote:
- Saulius Krasuckas wrote:
Today I have tried to compile ntoskrnl.exe, then checked out master branch, compiled stock Wine, then tried to run win32 app which do simple port I/O after it loads (GIVE)IO.SYS driver. Driver simply loaded, did its initialization and immediatelly exited.
It's enough to read this to see that you have no idea about how windows kernel works.
Hey, does reading DDK answers the question about what happens if driver is started as a process?
Please download DDK and read through examples.
I am trying to do so for several years already. Without success, however.
-
Marcus Meissner -
Saulius Krasuckas -
Vitaliy Margolen