Jens Nerche <[EMAIL PROTECTED]> wrote:
> Other things... page tables. We may want to write a pager that
> pages for our guest os. This makes the guest os pager out of
> work an we (host os and monitor) hold control over all pages.
Uh, while we might modify the guest OS for performance reasons,
I think the core virtualization should work *regardless* of what
the guest does. I'd like to be able to run anything under FreeMWare,
including hacks like Soft-ICE, or even FreeMWare itself ...
So we must IMO cope with the case where the guest does in fact
use the paging facilities of the processor.
> Or we give a set of pages to our guest (must be done while
> starting up, has anybody any idea, how to do?), then guest os
> pager works for guest tasks and guest may easily do swapping
> on hard disks. Don't know, what better, any comments?
The basic ideas we had discussed go about like this: we allocate
on startup a fixed set of pages, which are used to emulate the
'physical memory' of the guest. When the guest activates paging
and loads the PDBR, we trap this instruction, scan the page directory
and page tables that the guest wants to use, and build the *real*
page tables to correspond to the guest page tables, except that the
'guest' physical page numbers are replaced by the real physical page
numbers underlying those guest pages.
We then mark the physical pages holding page directory and page tables
as no-access, so that every attempted access by the guest of the page
tables traps to the monitor, which figures out what the guest wants to
do and emulates the same action on the real page tables.
> And another question: why do you want to scan guest code?
> May be we have to do this while emulating some instructions
> to detect what guest really wants to do, but I see no need
> to scan the whole code?
The problem is that some instruction do not trap. So, for example,
while *loading* the GDT register is a privileged instruction,
*retrieving* the current GDT address is not. Thus, the guest, when
attempting to scan its GDT, would really scan the *real* GDT, which
is not what we want.
A similar problem is that e.g. 'push cs' always works without trapping,
and hence we have a problem if the guest tries to examine the RPL bits
in the image of the selector on the stack. It would expect the RPL to
be zero, while in reality it would retrieve 3 under our virtualization
scheme.
Some of those problems can be fixed by other tricks. For the GDT base
address, we can simply always move the real GDT at the same address as
the guest has its GDT; we'd then use page protection to trap accesses
of the guest to its GDT and fake the results.
For the RPL of selectors, the problem seems difficult to solve; that's
why Kevin mentioned the SMM hack. If this doesn't work or we don't
want to use it, we probably have to fall back on pre-scanning.
The point of pre-scanning is that we need to scan *every* instruction
executed by the guest *before* it is executed, just to find out *which*
of the instructions are in fact 'dangerous' ones. We then replace
the dangerous instructions by e.g. breakpoint instructions, so that
they will trap when executed.
Bye,
Ulrich
