Re: [Xen-devel] [PATCH 08/15] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/11/16 19:41, Boris Ostrovsky wrote:
> On 11/23/2016 02:28 PM, Andrew Cooper wrote:
>>> SVM requires attributes of any NULL segment to be zero.
>> Where is this claim made?  Vol2 recommends that the VMM clear all
>> attributes, but the wording of the previous paragraph suggests that the
>> attributes would be ignored in this case.   The %ss bug, and some
>> experimentation on my behalf also indicate that they are ignored.
> 15.5.1 Basic Operation, Segment State in the VMCB:
>
> The VMM should follow these rules when storing segment attributes into
> the VMCB
> * For NULL segments, set all attribute bits to zero; otherwise, write
> the concatenation of bits 55:52 and 47:40 from the original 64-bit
> (in-memory) segment descriptors.
>
> I guess the preceding text is indeed unclear as to whether this is
> somehow enforced (in which case I am not sure I see the point of having
> this rule).

The quality if information in this regard is very poor.  Both Intel and
AMD expose the segment cache to hypervisors, without actually
documenting the behaviour and expectations.  I spent several weeks
during the development of XSA-191 trying to divide what actually
happens, especially in terms of what a guest can do to the segment cache
without suffering a VMEXIT.

One point I deliberately didn't highlight at the time in c/s 12bc22f791
is that such an emulated instruction, on AMD, discards the non-canonical
part of the base, and happily runs with a truncated address implicitly
sign extended.  If you happen to look back through my submissions, you
will find quite a few patches drip-feeding segmentation fixes and
improvements.  c/s ed00f17616 was another curious issue to stumble across.

~Andrew

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