kernel level drivers - next try

[Vitaliy Margolen]

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.