[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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"?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.