Re: [Xen-devel] [PATCH RFC] x86/32on64: don't modify guest descriptors without need

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.09.16 at 16:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 29/08/16 14:57, Jan Beulich wrote:
>> The less obvious (and potentially controversial) part is that of a call
>> gate with DPL < selector.RPL: Such gates can't be used either without
>> the hardware raising #GP, but the specific case of DPL=0 gets handled
>> in emulate_gate_op(). The purpose of the change is to avoid adjusting
>> a gate a second time when it did get adjusted already here, on the
>> assumption that guest OSes wouldn't normally install unusable gates
>> (i.e. we'd normally see DPL >= selector.RPL) and still have a way of
>> installing an unusable gate (by specifying a non-zero DPL right away).
>>
>> Aforementioned second time adjustments of gates are a problem for
>> environments where
>> - per-CPU GDTs get cloned from the boot CPU's after the boot CPU had
>>   already installed its GDT (e.g. Linux),
>> - individual descriptors get installed via hypercall prior to actually
>>   making the respective page a descriptor one (this could alternatively
>>   be taken care of by making do_update_descriptor() call
>>   check_descriptor() only when modifying a PGT_seg_desc page),
>> i.e. the hypervisor gets presented an already adjusted descriptor a
>> second time.
> 
> Are these problems which currently manifest themselves?

I've run into the first of the two issues when testing other gate
op emulation changes.

> I don't think we should be making any assumptions about what a guest
> might or might not do.

Generally I agree, but by modifying the RPL of the selector in the
gate descriptor we already fiddle with what the guest has given us.
Ideally we'd get away without doing so, but I can't see any
reasonable way to elsewhere store the two DPL bits. Hence I'd
prefer to at least get things as usable as possible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel