kernel level drivers - next try

[Rolf Kalbermatter]

Saulius Krasuckas [saulius2 at ar.fi.lt] 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.

The IO sys driver I have worked with and made myself in the past

http://opengtoolkit.cvs.sourceforge.net/opengtoolkit/portIO/c_source/

(The whole opengtoolkit project is really related to a software called LabVIEW
and this was a driver to give direct IO access to it, but the portio kernel
driver and its user space DLL can be used from any application that can call DLLs).

did use a number of specific kernel functions such as 

NTKERNELAPI void Ke386SetIoAccessMap(int, IOPM *);
NTKERNELAPI void Ke386QueryIoAccessMap(int, IOPM *);
NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS, int);
NTKERNELAPI NTSTATUS PsLookupProcessByProcessId(IN ULONG ulProcId, OUT PEPROCESS * pEProcess);

which all were and maybe still are considered undocumented. These are for
manipulating the IO permission map so that applications can directly use the
inp and outp opcode in application space for enabled IO adresses.

Alternatively it can access IO ports through a kernel driver call using a combination
of:

HalTranslateBusAddress
MmMapIoSpace

So all these functions together with several more for standard kernel driver
interaction with the system need to be exported by the subsystem that loads
them (eg. ntoskrnl.exe or its helpers like hal.dll etc).

I'm not positive these can all be easily added to a process operating in user space
without some specific kernel support for this functionality and in fact allowing
full IO access to a user space application such as Wine just doesn't seem safe
to me.

Especially the first method while being a bit faster for standard IO access is
probably a real trouble to implement. I have not found a way to manipulate the
Linux IO permission map without a specific kernel extension and don't think such
an extension would ever make it in the mainstream kernel.

Rolf Kalbermatter