Jens Nerche <[EMAIL PROTECTED]> wrote:
> > - some selectors must not be loaded while guest code ist
> > running (this applies to the ring-0 monitor selectors)
> With the right GDT the guest may load into its selectors
> what it wants...
The monitor segment descriptors *need* to be in the GDT.
Otherwise, what CS selector do you suppose should be entered
into the IDT active while running guest code?
> > - guest "ring-0" selectors will need to have their RPL
> > adjusted to 3
> Why? While checking, the processor will compute the epl=max(cpl,rpl)
> and use epl. Since cpl is 3, epl is always 3, independently from rpl.
> As I see it, RPL is to restrict *kernels* access to memory, but
> out guest runs as user application.
You cannot load any selector with RPL!=CPL into %ss, for one.
Also when performing an IRET, the *RPL* decides about whether
an OUTER-LEVEL or SAME-LEVEL return is to be performed, so you
need RPL 3 for the %cs value as well.
> > - when modifying the CS register, various monitor-internal
> > structures need to be changed (the descriptor needs to
> > be "activated", the guest CPL value needs to be adjusted)
> cs can't be changed with mov, only jmp, call or ret may load cs.
Eh? I'm not sure what this has to do with 'mov' ...
> >This means that you can't simply copy the segment registers.
> >
> >Instead, you'll have to implement a mechanism that "carefully"
> >changes the segment values, using algorithms similar to the
> >ones used by the monitor for emulating 'mov Xs, ...' and
> >lcall/ljmp/ret/iret.
> Changed segment virtualization should do this. I see no reason
> for not letting guest set its selectors now.
If you simply copy a value to guest_context, just where does
segment virtualization happen? This is exactly what I am saying:
you need to *perform* segment virtualization here.
We are not talking about 'letting guest set its selectors' at all,
b.t.w. We are talking about letting the *user mode* app set
selectors to be used by the guest when it runs the next time.
Bye,
Ulrich
