direct access to IO space [Was: kernel level drivers - next try]
Saulius Krasuckas
saulius2 at ar.fi.lt
Mon Oct 16 15:57:56 CDT 2006
* 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
More information about the wine-devel
mailing list