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
>
>
>