* 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
