Re: [patch] lazy TSS's I/O bitmap copy ...

[Alan Cox]

On Llu, 2004-08-23 at 23:18, Davide Libenzi wrote:
> > >	 The check for the I/O opcode can certainly be 
> > > done though, even if it'd make the code a little bit more complex.
> > 
> > Have to be very careful there to avoid nasty security issues. And with
> > ins/outs, you can have various prefixes etc, so decoding is not as trivial
> > as it could otherwise be. Even the regular in/out can have a data size
> > overrides..

And an attacker can be changing the mappings in another thread at the
same time. Now you see it, now you don't. This gets quite fun with
writing fixups to user space code but isnt a big deal for reads.

> > In short, I think that if we do this at all, I'd much rather just do the
> > simple "trap twice" thing that Davide did. It's too easy to get it wrong
> > otherwise.
> 
> IMHO since the GPF path is not a fast path like a page fault, we shouldn't 
> be in bad shape with the current approach. No?

Even the X server doesn't generally make heavy use of I/O port access on
any vaguely modern hardware. The BIOS might but its already doing some
of its own vm86 fixups for this.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/