"Kevin P. Lawton" <[EMAIL PROTECTED]> wrote:
> * save current page mapping of some_address (private copy)
> * change page mapping of some_address to guest data with user access
> * INVLPG (some_address)
> * step 1 instruction (add)
> * restore page mapping to private page
> * INVLPG (some_address)
> * act on change of data accordingly
[snip]
> * save data at some_address
> * change data at some_address if needed to what guest should see
> * step 1 instruction (add)
> * act on data change
> * restore data if need be
Hmmm. This would work, if we can cope with the race conditions
it introduces: on an SMP machine, if we want allow the guest to
actually use multiple processors, this sort of manipulation would
introduce rather difficult to solve races. On the other hand,
we'll probably need to restrict the guest to one processor anyway ...
Even on a single processor machine, we might have to disable
interrupts while the data at that address is modified (e.g. if
the page in question holds the real IDT or some data structure
that might be accessed by one of our interrupt handlers).
[snip]
> Mark pages in question with read-only. Now guest code
> running at ring1 will generate exceptions, but interrupt
> code will run. Even the page tables would have to be
> read-only while running the guest. This is all
> assuming we run with the CR0.WP flag set.
OK, I see. This does indeed protect against modifications.
It does *not* protect against *read* access to that memory area,
however, which means that we'd have to catch (at least) sidt
instructions even in ring-3 code ... (Even so, we still can't
guarantee that the guest doesn't manage to read this memory by
some other means.)
[snip]
> Very true. We'd need to keep tabs on any memory regions
> which we had cached page tables for, whether active or
> not.
>
> There is no way to know when a page table goes out
> of commission. Probably allocate memory for a certain
> number of virtualized page tables. When we want to create
> a new one, just dump one that is the least used.
Yes; what I was concerned about is that a memory area which
we think still to be a page table could have been re-allocated
by the guest OS to some completely different purpose. This might
mean that it could be extremely frequently accessed (say, if it is
now used as call stack page or so), and on every access our handler
would try to interpret the arbitrary changes as modifications of a
page table ... This could easily be very inefficient.
Of course, the handler might simply mark the page as modified (and
stop further monitoring) on the first access; in this case, the cache
would simply be thrown away at that point.
Bye,
Ulrich
