Re: direct access to IO space [Was: kernel level drivers - next try]
James == James Courtier-Dutton [EMAIL PROTECTED] 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[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: direct access to IO space [Was: kernel level drivers - next try]
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
Re: direct access to IO space [Was: kernel level drivers - next try]
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
Re: direct access to IO space [Was: kernel level drivers - next try]
Saulius Krasuckas wrote: * On Sat, 14 Oct 2006, James Courtier-Dutton wrote: * Rolf Kalbermatter wrote: * Saulius Krasuckas [EMAIL PROTECTED] 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
Re: direct access to IO space [Was: kernel level drivers - next try]
* On Sat, 14 Oct 2006, James Courtier-Dutton wrote: * Rolf Kalbermatter wrote: * Saulius Krasuckas [EMAIL PROTECTED] 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
Re: direct access to IO space [Was: kernel level drivers - next try]
* 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
Re: direct access to IO space [Was: kernel level drivers - next try]
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 [EMAIL PROTECTED] 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
