From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls Date: Tue, 12 Jan 2016 00:33:38 -0700 Message-ID: <5694BA6202000078000C5C6A@prv-mh.provo.novell.com> References: <1452520774-16794-1-git-send-email-andrew.cooper3@citrix.com> <5693CDE302000078000C5788@prv-mh.provo.novell.com> <5693E3BD.6070009@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5693E3BD.6070009@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: StefanoStabellini , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 11.01.16 at 18:17, wrote: > On 11/01/16 14:44, Jan Beulich wrote: >>>>> On 11.01.16 at 14:59, 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