Re: [Xen-devel] [PATCH v2] x86/PV: fix/generalize guest nul selector handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/09/17 09:41, Jan Beulich wrote:
> Segment bases (and limits) aren't being cleared by the loading of a nul
> selector into a segment register on AMD CPUs. Therefore, if an
> outgoing vCPU has a non-zero base in FS or GS and the subsequent
> incoming vCPU has a non-zero but nul selector in the respective
> register(s), the selector value(s) would be loaded without clearing the
> segment base(s) in the hidden register portion.
>
> Since the ABI states "zero" in its description of the fs and gs fields,
> it is worth noting that the chosen approach to fix this alters the
> written down ABI. I consider this preferrable over enforcing the
> previously written down behavior, as nul selectors are far more likely
> to be what was meant from the beginning.
>
> The adjustments also eliminate an inconsistency between FS and GS
> handling: Old code had an extra pointless (gs_base_user was always zero
> when DIRTY_GS was set) conditional for GS. The old bitkeeper changeset
> has no explanation for this asymmetry.
>
> Inspired by Linux commit e137a4d8f4dd2e277e355495b6b2cb241a8693c3.
>
> Additionally for DS and ES a flat selector is being loaded prior to the
> loading of a nul one on AMD CPUs, just as a precautionary measure
> (we're not currently aware of ways for a guest to deduce the base of a
> segment register which has a nul selector loaded).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Even if not strictly as written, this is clearly what the ABI should
be.  The use of nul non-zero selectors is basically only for testing and
exploiting corner cases these days, so this shouldn't impact plausible
usecases.

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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