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

["Jan Beulich" <JBeulich@suse.com>]

>>> 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.

> * 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.

> * 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.

> So from one point of view, sufficient justification for this change is
> "because the Linux way isn't the only valid way to do this".

But otoh bypassing a layer is generally a bad thing. Any "normal"
OS wouldn't want to allow user mode to do arbitrary things under
its feet. Any OS full trusting what would be user mode could as
well run applications in ring 0.

Plus - see privcmd - any OS wanting to expose hypercalls can do
so by whatever mechanism is appropriate in that OS.

Jan