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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/08/16 14:57, Jan Beulich wrote:
> There are two cases: The obvious one is that system gates with type 0
> shouldn't have what might be their DPL altered - such descriptors can't
> be used anyway without incurring a #GP, and hence adjusting its DPL is
> only risking to confuse the guest.

This is fine.

>
> 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 don't think we should be making any assumptions about what a guest
might or might not do.

~Andrew

>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> RFC reason: As mentioned above the change in behavior here might be
>             controversial. The main question here appears to be whether
>             this is viewed as having the potential for undermining
>             guest OS security.


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