Re: kernel level drivers - next try

[Rolf Kalbermatter]

Saulius Krasuckas [saulius2(a)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

kernel level drivers - next try

[James Courtier-Dutton]

Rolf Kalbermatter wrote:
> Saulius Krasuckas [saulius2(a)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

Why do we need to give an application direct access to IO space?

direct access to IO space [Was: kernel level drivers - next try]

[Saulius Krasuckas]

* On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
> * Rolf Kalbermatter wrote:
> > * Saulius Krasuckas [saulius2(a)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.
> > > ...
> > > 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.
> > >   ...
> > > Why do we need to give an application direct access to IO space?

Imagine some new motherboard model with uniq internal debugging device.  
And its supporting software designed only for Win32 platforms.  Or imagine 
some proprietary portable music player connected via LPT and using its own 
protocol.  User wants to make them work on linux.  Just that's why.

I see two reports in out bugzilla on this topic: [6], [7].

IMHO, we don't need to give this access to all of applications.  We just 
need a way to redirect operation from a particular win32 app to small 
piece of "raw-io-unrestricted" code.


[6] http://bugs.winehq.org/show_bug.cgi?id=3358#c6
[7] http://bugs.winehq.org/show_bug.cgi?id=3836#c8

direct access to IO space [Was: kernel level drivers - next try]

[James Courtier-Dutton]

Saulius Krasuckas wrote:
> * On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
> > * Rolf Kalbermatter wrote:
> > > * Saulius Krasuckas [saulius2(a)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.
> > > > ...
> > > > 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.
> > > >   ...
> > > > Why do we need to give an application direct access to IO space?
>
> Imagine some new motherboard model with uniq internal debugging device.  
> And its supporting software designed only for Win32 platforms.  Or imagine 
> some proprietary portable music player connected via LPT and using its own 
> protocol.  User wants to make them work on linux.  Just that's why.
>
> I see two reports in out bugzilla on this topic: [6], [7].
>
> IMHO, we don't need to give this access to all of applications.  We just 
> need a way to redirect operation from a particular win32 app to small 
> piece of "raw-io-unrestricted" code.
>
> [6] http://bugs.winehq.org/show_bug.cgi?id=3358#c6
> [7] http://bugs.winehq.org/show_bug.cgi?id=3836#c8

This feature is being ask for by people who don't understand what most
hardware requires from a "driver".
1) IO ports or memory mapped IO.
2) DMA handler
3) IRQ handler

Getting IO port access in wine really is not going to help a whole lot!

James

direct access to IO space [Was: kernel level drivers - next try]

[Uwe Bonnes]

> > > > > "James" == James Courtier-Dutton <James(a)superbug.co.uk> writes:

James> This feature is being ask for by people who don't understand what
    James> most hardware requires from a "driver".  1) IO ports or memory
    James> mapped IO.  2) DMA handler 3) IRQ handler

    James> Getting IO port access in wine really is not going to help a
    James> whole lot!

For a lot of programms used to program electronic devices, IO port access
under wine would help a lot!
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

direct access to IO space [Was: kernel level drivers - next try]

[Marcus Meissner]

On Mon, Oct 16, 2006 at 11:45:01PM +0300, Saulius Krasuckas wrote:
> * On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
> > * Rolf Kalbermatter wrote:
> > > * Saulius Krasuckas [saulius2(a)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.
> > > > ...
> > > > 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.
> > > >   ...
> > > > Why do we need to give an application direct access to IO space?
>
> Imagine some new motherboard model with uniq internal debugging device.  
> And its supporting software designed only for Win32 platforms.  Or imagine 
> some proprietary portable music player connected via LPT and using its own 
> protocol.  User wants to make them work on linux.  Just that's why.
>
> I see two reports in out bugzilla on this topic: [6], [7].
>
> IMHO, we don't need to give this access to all of applications.  We just 
> need a way to redirect operation from a particular win32 app to small 
> piece of "raw-io-unrestricted" code.

We have this already to some degree, see dlls/winedos/ioports.c.

Ciao, Marcus

direct access to IO space [Was: kernel level drivers - next try]

[Saulius Krasuckas]

* On Sat, 14 Oct 2006, Rolf Kalbermatter wrote:
> The IO sys driver I have worked with and made myself in the past
> 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.

These are fns "doable" in a pretty strightforward way, IMHO.
> Alternatively it can access IO ports through a kernel driver call using 
> a combination of:
>
> HalTranslateBusAddress
> MmMapIoSpace
>
> 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.

And the last one is "undoable" without some bigger emulation, I guess.  
Luckily we have only bugreports about a need of some old-fashioned port 
I/O... ;)
> 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.

Yes for the last statement, but extraordinary user's mileage may vary.  
It can choose between (a) running wine as root and (b) running 
LIDS-patched kernel [8] plus this command:

 # lidsadm -A -s /path/to/some_wine_binary_piece -o CAP_SYS_RAWIO  -j GRANT

Right?  Then it would be nice to get this "some_wine_binary_piece" as a 
separate executable file.
Well, maybe I should have gone asleep instead of writing this ;)


[8] http://www.securityfocus.com/infocus/1502

direct access to IO space [Was: kernel level drivers - next try]

[Damjan Jovanovic]

> > 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.
>
> And the last one is "undoable" without some bigger emulation, I guess.
> Luckily we have only bugreports about a need of some old-fashioned port
> I/O... ;)
> > 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.
>
> Yes for the last statement, but extraordinary user's mileage may vary.
> It can choose between (a) running wine as root and (b) running
> LIDS-patched kernel [8] plus this command:
>
> # lidsadm -A -s /path/to/some_wine_binary_piece -o CAP_SYS_RAWIO  -j GRANT

Couldn't you also unmap the I/O ports memory and catch segmentation
faults referring to that area, then reroute them through some system
service running as root? It's safer than running wine as root.
> Right?  Then it would be nice to get this "some_wine_binary_piece" as a
> separate executable file.
> Well, maybe I should have gone asleep instead of writing this ;)
>
> [8] http://www.securityfocus.com/infocus/1502

direct access to IO space [Was: kernel level drivers - next try]

[Kuba Ober]

> > Yes for the last statement, but extraordinary user's mileage may vary.
> > It can choose between (a) running wine as root and (b) running
> > LIDS-patched kernel [8] plus this command:
> >
> > # lidsadm -A -s /path/to/some_wine_binary_piece -o CAP_SYS_RAWIO  -j
> > GRANT
>
> Couldn't you also unmap the I/O ports memory and catch segmentation
> faults referring to that area, then reroute them through some system
> service running as root? It's safer than running wine as root.

All that one needs is a small setuid-root wrapper that grants needed ioperms 
and then folds back to regular user and execs wine.

Cheers, Kuba