>> > /*
>> > * We don't allow to modify segment registers
>> > for now;
>> > * we don't want user mode to be able to crash
>> > the kernel ...
>> > */
>> >
>> > I don't see any reason for this. Is this still
>> > applicable ?
>
>To answer the question: Yes, this is of course still
>applicable. The reasons are simple:
>
> - 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...
> - 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.
> - 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.
>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.
jens
