Saulius Krasuckas [saulius2@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
Rolf Kalbermatter wrote:
Saulius Krasuckas [saulius2@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?
* On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
- Rolf Kalbermatter wrote:
- Saulius Krasuckas [saulius2@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
Saulius Krasuckas wrote:
- On Sat, 14 Oct 2006, James Courtier-Dutton wrote:
- Rolf Kalbermatter wrote:
- Saulius Krasuckas [saulius2@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
"James" == James Courtier-Dutton James@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!
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@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
* 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 ;)
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 ;)
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
-
Damjan Jovanovic -
James Courtier-Dutton -
Kuba Ober -
Marcus Meissner -
Rolf Kalbermatter -
Saulius Krasuckas -
Uwe Bonnes