Ramon van Handel wrote:
>
> Kevin P. Lawton wrote:
> > Mark pages in question with read-only. Now guest code
> > running at ring1 will generate exceptions, but interrupt
> > code will run.
>
> Hey wait a moment... as far as I know, when you've got
> WP set in CR0 then *every* piece of code will trap on
> writing to R/O pages. Is this not true ?
Yes, this is my understanding. It's what you would want,
ring1 and ring3 guest code generating exceptions upon
writes to r/o protected pages. The monitor could do CR0.WP=0
to be able to modify without an exception.
This is no different than what we'd have to do if
we push ring0 guest code down to ring3 instead, and
mark pages with supervisor to generate exceptions at
the same place.
I was thinking in terms of a ring1/3 strategy mainly for
the case where the guest OS isn't bothered by letting
certain instructions go through so we didn't have to
scan instructions etc. This would also require PVI
to be implemented properly for ring1 and I'm not
certain that it is.
More thought needs to be put into seeing if it could
work for a general strategy, and seeing if we can fix
the other techniques it breaks. I'm not sure the
TLB hack is an issue. Seems like we could make data
reads/writes see a page-not-present instead of a supervisor
page, and code accesses see a readable supervisor page.
Anyways, we might as well talk about as many strategies as
possible, then thread together ones that work best when
put together. It's also good to be aware of potential
accelerations beyond that, and how they will plug into
the strategies we chose.
-Kevin
