Re: [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 12/01/16 07:33, Jan Beulich wrote:
>>>> On 11.01.16 at 18:17, <andrew.cooper3@citrix.com> wrote:
>> On 11/01/16 14:44, Jan Beulich wrote:
>>>>>> On 11.01.16 at 14:59, <andrew.cooper3@citrix.com> wrote:
>>>> Currently, hypercalls issued from HVM userspace will unconditionally fail
>>>> with -EPERM.
>>>>
>>>> This is inflexible, and a guest may wish to allow userspace to make
>>>> hypercalls.
>>> I thought previous discussion had made clear that routing these
>>> through ioctls or alike is the right approach, and hence the patch
>>> isn't needed. The more that an all-or-nothing approach seems
>>> pretty bold.
>> All other issues fixed in v2, but to answer this one specifically.
>>
>> In it inappropriate for Xen to presume that all guests want Linux-like
>> handing of situations like this.  It is simply not true.
>>
>> As part of getting my test framework ready to publish, I attempted to
>> port my XSA-106 unit tests to PV guests.  I have shelved that work as I
>> don't have sufficient time to fix PV trap handing in Xen at this present
>> time, but do plan to fix them in due course.
>>
>> The bugs I have identified so far are:
>> * "INT n" handling assumes the instruction was 2 bytes long
>> * In some circumstances, Xen crashes the domain rather than injecting
>> #NP[sel]
>> * In most circumstances, Xen delivers #GP[sel] where #NP[sel] would be
>> correct
> All of these could be considered part of the awareness
> requirements towards guests.

The first causes corruption of process state in circumstances which
wouldn't under native, including userspace state.

You could make that argument for the final two.  I reckon it is an
unreasonable requirement.

>
>> * Not possible to have non-dpl3 descriptors for #BP and #OF
> Actually the issue is broader I think (I've stumbled across this
> limitation before, namely in the context of the #AC issue having
> been the subject of a recent XSA) - you can't associate a DPL
> with any exception vector.

Ah - I had not patched Xen up sufficiently for the unit test to notice
this (the domain crashes rather than #NP exceptions were prohibitive).

>
>> * Not possible to mark an existing descriptor as not-present
> "Not easily possible" I suppose you mean, since one can by re-
> writing the entire table.

Can't be done atomically.  Even if interrupts are disabled, there is a
window where NMIs and MCEs would be lost.


Writing a PV guest from scratch has been very enlightening to
demonstrate how much of a trainwreck the ABI is.  Almost nothing is
documented.  Some bits which are documented are misleading.  Several
areas needlessly deviate from x86 architectural behaviour.  Almost any
deviation from the way Linux does things ends up in situations which
don't function.

~Andrew