direct access to IO space [Was: kernel level drivers - next try]
damjan.jov at gmail.com
Tue Oct 17 11:21:52 CDT 2006
> > 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  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 ;)
>  http://www.securityfocus.com/infocus/1502
More information about the wine-devel