Ramon van Handel wrote:
> Okay, so it requires us to be careful because a bug
> in plex86 may be a security hole. But plex is
> quite dangerous anyway... assuming we can fix all the
> bugs, I don't think running at ring0 HAS to be a problem..
> that's what prescanning is for, after all!
Ugh. Well, first architecturally, you'd have to move to using
"shortened" segments so that data segment accesses could not
generate linear addresses in the domain of the monitor. Prescanning
can not save us from this.
Since a r0-->r0 exception does not reload SS:ESP, you'd have to
gate the monitor handlers to task switches. Otherwise, if there
is no room on the guest stack, you are hosed.
In your method, you can not allow host user code to modify
the translation buffers, to re-optimize it, since it would
then be incredibly easy to make it do whatever you wanted.
With r3 guest code, when/if the code gets away from us, it
doesn't pose a security hole, the code just doesn't do
what it should. This lets us focus on a smaller domain of
code for security issues.
I'm not sure at all what your 16-bit code strategy is, in relation
to this modified architecture.
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
