Bochs Software Company <[EMAIL PROTECTED]> wrote:
[ Sorry for the long delay in replying to this post; I've finally
found some time now to address a few of the points you made. ]
> What better mechanism to virtualize the guest page tables
> than the paging unit! We can use protection flags in the
> page table entries to be notified when the guest OS attempts
> an access to the page tables. At this point, we can
> feed it the data it expects (read), or maintain the effect
> that it intended (write). In this way, the guest never
> senses our modifications.
As the guest could be using any of a large number of instructions
to access the page tables (and other virtualized structures) --
basically any instruction that accesses memory -- we'll probably
need a quite complete x86 instruction emulator to do so ...
(We'll probably need that anyway, I just wanted to point it out.)
[snip]
> APPROACH #2
>
> Rather than push guest system code down to ring3, we could push
> it down to ring1 instead. This would yield a privilege level
> mapping such as the following:
>
> guest monitor
> 0--+ 0
> 1 +--->1
> 2 2
> 3------>3
>
> As far as page protection goes, this would offer us an
> environment, where we could use the page protection
> mechanisms more natively, and which would only require
> one private set of page tables per each guest set. Since
> x86 paging groups all CPLs of {0,1,2} as supervisor-mode,
> the shift from 0 to 1 in the example above does not
> affect privilege levels with respect to paging.
Eh, but how to you propose to prevent the guest OS from
corrupting monitor code/data pages? While guest code is
running, at least the IDT and the interrupt handlers
must be mapped into the virtual address space. This means
that these pages can be modified by any code running in
supervisor mode, which would include the guest OS ...
Thus, the guest OS could write itself an interrupt gate
to ring 0 into the IDT, and completely take control of
the computer ...
[ Well, I guess this might be prevented by thoroughly
pre-scanning the guest OS code, but then again, it
seems difficult (how to decide whether an arbitrary
write to a computed address might hit the real IDT
or not?) ]
[snip]
> A more complex approach would be to save virtualized
> page table information across PDBR reloads. The idea
> here is that when the guest OS schedules a task who's
> page tables are already virtualized and stored, we can
> save a number of page faults and execution of associated
> monitor code, which would otherwise be incurred from
> the dynamic rebuilding of the page tables.
Of course, you need to take into account that the page
tables might be modified while they are *not* currently
active ... Thus, you can't simply re-use the old monitor
page tables if the guest reloads a PDBR value that we've
already seen in the past.
So, you either have to examine the page tables in detail
anyway, to check for potential modification, or else you
track that memory for modifications even while the it is
*not* actively used as page tables. (How do you detect
that the page table has been destroyed for good, and the
memory is reused for something completely different?)
Bye,
Ulrich
