Re: [Xen-devel] [PATCH] xen/pvh: Fix segment selector ABI

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.02.2020 14:56, Andrew Cooper wrote:
> On 10/02/2020 13:47, Jan Beulich wrote:
>> On 10.02.2020 14:29, Andrew Cooper wrote:
>>> On 10/02/2020 13:22, Jan Beulich wrote:
>>>> On 08.02.2020 16:19, Andrew Cooper wrote:
>>>>> --- a/docs/misc/pvh.pandoc
>>>>> +++ b/docs/misc/pvh.pandoc
>>>>> @@ -23,7 +23,7 @@ following machine state:
>>>>>   * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’
>>>>>     and a limit of ‘0xFFFFFFFF’. The selector value is unspecified.
>>>>>  
>>>>> - * `ds`, `es`: must be a 32-bit read/write data segment with a base of
>>>>> + * `ds`, `es`, `ss`: must be a 32-bit read/write data segment with a 
>>>>> base of
>>>>>     ‘0’ and a limit of ‘0xFFFFFFFF’. The selector values are all 
>>>>> unspecified.
>>>> Wouldn't this want accompanying with an adjustment to
>>>> xen/arch/x86/hvm/domain.c:check_segment(), which right now
>>>> isn't in line with either old or new version of this doc?
>>> What do you thing is missing?  It too is written with the expectation of
>>> %es being set up, which I checked before sending this patch.
>> The function for example looks to permit zero segment attributes
>> for both DS and ES. It also looks to permit non-writable
>> attributes for both, and a non-readable CS.
> 
> It is not a PVH-auditing function.
> 
> It is reachable from plain HVM guests, and is only supposed to be a
> minimum set of checks to prevent a vmentry failure of the
> newly-initialised vcpu state.  (Whether it actually meets this goal is a
> separate matter.)

Well, that's fine, but what other place am I missing then where the
documented restrictions actually get enforced? Or if we don't mean
to enforce them, then perhaps there should be a distinction in the
doc between "must" and "should"?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel